BAB 2 Tinjauan Pustaka 2.1 Teori yang Berkaitan Dengan Database 2.1.1 Data Seperti pendapat yang diungkapkan oleh Laudon dan Laudon (2012:375), data merupakan kumpulan fakta-fakta kasar yang menunjukkan kejadian yang terjadi dalam organisasi atau lingkungan fisik sebelum fakta tersebut diolah dan ditata menjadi bentuk yang dapat dipahami. 2.1.2 Database Seperti yang disampaikan oleh Connolly dan Begg (2010:65), bahwa database adalah kumpulan data yang saling terhubung secara logis dan deskripsi dari data tersebut, dirancang untuk menemukan informasi yang dibutuhkan oleh sebuah organisasi. Dalam merancang database, salah satu hal yang perlu diperhatikan adalah efisiensi. Banyaknya data yang redudansi dapat mengurangai efisiensi pada database sehingga perlu dilakukan normalisasi. Database ini digunakan tidak hanya oleh satu orang maupun satu departemen, database dapat digunakan oleh seluruh departemen dalam perusahaan. Database ini akan menjadi sumber data yang digunakan secara bersama dalm perusahaan. Database tidak lagi dimiliki oleh satu departemen tetapi sumber perusahaan yang saling berbagi. Untuk mendapatkan database. Dengan hanya database saja tidak cukup, diperlukan Database Management System (DBMS) untuk dapat menggunakan database. Database bisa diartikan sebagai suatu file data yang memiliki tabel, record, field, index, query, filter dan view. Berikut adalah definisi umum isi sebuah file database. 7 8 1. Tabel Tabel adalah sekelompok record data, masing-masing berisi informasi yang sejenis. 2. Record Record adalah entri tunggal dalam tabel. Bisa saja disebut sebagai baris mengingat sebuah tabel terdiri dari baris (record) dan kolom (field). 3. Field Field adalah item tertentu dalam tabel. Bisa disebut sebagai kolom. 4. Index Index adalah field kunci yang ditujukan ke suatu record yang spesifik serta diurutkan dalam urutan tertentu. 5. Query Query adalah perintah SQL yang dirancang untuk memanggil kelompok record tertentu dari satu tabel/lebih. 6. View View merupakan tabel virtual yang berisi record dari berbagai tabel. Fungsi utamanya untuk memudahkan untuk mendapatkan data yang spesifik dari berbagai tabel. 2.1.3 DBMS (Database Management System) Menurut Connolly dan Begg (2010:66), DBMS perangkat lunak sistem yang dapat mendefinisikan, membuat, memelihara, dan mengontrol akses ke basis data. Seperti yang dikatakan oleh Connolly dan Begg (2010:99-104), fungsi daripada DBMS antara lain: 1. Penyimpanan, Pengambilan, dan Update Data DBMS harus menyediakan pengguna dengan kemampuan untuk menyimpan, mengambil, dan update data dalam database. 2. Sebuah User-Accessible Pengguna) Catalog (Katalog Data untuk 9 Dalam DBMS harus menyediakan katalog yang mana berisi deskripsi dari data yang disimpan di dalamnya dan informasi mengenai siapa saja yang diberi hak akses untuk mengakses data di dalamnya. Pada dasarnya yang disimpan dalam sistem katalog terdiri dari: a. Nama, tipe, dan ukuran data. b. Nama hubungan. c. Batasan integritas dalam data. d. Nama pengguna yang memiliki hak akses ke basis data. e. Data yang dapat diakses pengguna dan tipe hak akses. f. Skema eksternal, konseptual, internal serta pemetaan antar skema. g. 3. Statistik pemakaian. Mendukung transaksi DBMS harus menyediakan sebuah mekanisme yang dapat melakukan perubahan terhadap transaksi yang sudah terjadi untuk user. a. Layanan kontrol konkurensi DBMS harus dapat membuat sebuah sebuah cara kerja dimana dapat mengatur pengguna sehingga saat pengguna merubah basis data bersamaan tidak terjadi crash data. b. Layanan perbaikan Dalam satu DBMS, harus ada mekanisme untuk memperbaiki basis sebuah data yang bermasalah dengan menggunakan cara apa pun. c. Layanan otorisasi DBMS harus dapat menyediakan validasi untuk dapat memastikan bahwa user yang hendak mengaksesnya itu memang sudah memiliki otoritas. d. Mendukung komunikasi data Sebuah DBMS harus dapat menghubungkan antar perangkat lunak dimana digunakan untuk komunikasi data. e. Layanan integritas 10 Sebuah DBMS harus dapat menyediakan cara untuk memastikan data dalam basis data dan perubahan data tersebut dapat mengikuti peraturan yang telah diatur sebelumnya. f. Memberikan kemampuan independensi data Pada DBMS harus memiliki fasilitas dimana mendukung independensi program dari struktur basis data. g. Layanan utilitas Sebuah DBMS harus menyediakan sekumpulan layanan utilitas, seperti: • Fasilitas import data. • Fasilitas monitoring. • Program analisis statistik. • Fasilitas pengaturan ulang indeks. 4. Layanan kontrol konkurensi DBMS harus menyediakan mekanisme untuk memastikan bahwa database diperbarui dengan benar ketika beberapa pengguna memperbarui database secara bersamaan. 5. Pemulihan layanan DBMS harus memberikan mekanisme untuk memulihkan database dalam hal database rusak dengan cara apapun. 6. Layanan otorisasi DBMS harus menyediakan mekanisme untuk memastikan bahwa hanya pengguna yang berwenang dapat mengakses database. 7. Dukungan untuk komunikasi data DBMS harus mampu mengintegrasikan dengan software komunikasi. 8. Layanan integritas DBMS harus memberikan sarana untuk memastikan bahwa kedua data dalam database dan perubahan pada data mengikuti aturan-aturan tertentu. 11 9. Layanan untuk mempromosikan independensi data DBMS harus mencakup fasilitas untuk mendukung kemandirian program dari struktur aktual dari database. 10. Layanan utilitas DBMS harus menyediakan satu set layanan utilitas. 2.1.3.1 Fasilitas DBMS (Database Management System) Dari penerapan sebuah DBMS, tentunya akan mendapatkan fasilitas yang akan menguntungkan perusahaan yang menerapkan DBMS itu sendiri. Diantaranya fasilitas yang akan di dapatkan seperti yang dikutip dari Connolly dan Begg (2010:66), fasilitas yang disediakan oleh DBMS antaralain : 1. Data Definition Language (DDL) yang memungkinkan pengguna untuk menspesifikasikan tipe dan struktur data, serta batasan pada data yang disimpan dalam basis data. 2. Data Manipulation memungkinkan Language pengguna (DML) untuk yang memasukkan, mengubah, menghapus, dan menampilkan data dari basis data. 3. Fourth-Generation Languages (4GLs) yang memungkinkan pengguna tidak melakukan apa yang program lakukan, melainkan mendefinisikan parameter untuk alat-alat yang menggunakan mereka untuk menghasilkan program aplikasi. 2.1.3.2 Keuntungan dan Kekurangan DBMS (Database Management System) DBMS menjanjikan banyak keuntungan yang dapat digunakan, namun tentunya DBMS juga memiliki kekurangan yang perlu diperhatikan. Pertama-tama perlu melihat keuntungan apa saja yang diberikan oleh DBMS. Menurut 12 Connolly dan Begg (2010:77-80), keuntungan dalam menggunakan DBMS ialah: 1. Mengendalikan pengulangan data (control of data redudancy) Database dimana tempat menampung banyaknya data yang mana dari banyaknya data tersebut memungkinkan adanya pengulangan data. Oleh karena itu mengendalikan dibutuhkannya pengulangan Database data dengan dalam cara mengintegrasikan file sehingga berbagai data yang sama tidak akan disimpan dalam database, akan tetapi hal ini tidak menghilangkan semua pengulangan data yang ada di database secara menyeluruh, melainkan hanya membuat jumlah pengulangan data dapat dikontrol. 2. Konsistensi data Dengan mengontrol perulangan data, dapat mengurangi resiko terjadinya ketidak konsistensian yang terjadi. Jika data yang disimpan hanya sekali dalam database, maka berbagai perubahan bagi nilai data tersebut juga hanya dilakukan satu kali, dan nilai tersebut harus tersedia kepada semua pengguna. Dan jika item data yang disimpan lebih dari sekali dan sistem menyadari hal ini, sistem ini dapat memastikan bahwa semua salinan item disimpan secara konsisten. 3. Semakin banyak informasi yang didapat dari data yang sama Dengan mengintegrasikan data operasional, dapat memungkinkan perusahaan untuk memperoleh informasi tambahan dari data yang sama. 4. Pembagian data (Sharing of data) Database merupakan bagian dari keseluruhan organisasi dan dapat dibagikan ke semua pengguna yang mempunyai wewenang. 13 14 5. Meningkatkan integritas data Integritas data mengacu pada validitas dan konsistensi data yang disimpan, integritas biasanya diekspresikan dalam istilah batasan, yang berupa aturan konsisten yang tidak boleh dilanggar oleh database, dan dapat memungkinkan DBA untuk menjelaskan, dan memungkinkan DBMS untuk membuat batasan integritas. 6. Meningkatkan keamanan data Meningkatkan keamanan data dimana memproteksi database dari user yang tidak memiliki wewenang. 7. Penerapan standarisasi Integrasi memungkinkan DBA (Database Administrator) untuk mendefinisikan dan membuat standard yang diperlukan. Standarisasi ini termasuk standarisasi departemen, organisasi, nasional, dan internasional dalam hal format data, dan berguna untuk memfasilitasi pertukaran data antara sistem, ketepatan, penamaan standarisasi dokumentasi, prosedur update, dan aturan pengaksesan. 8. Pengurangan biaya Dimana semua data operasional organisasi dipusatkan ke dalam database dan membuat aplikasi yang bekerja menghasilkan penyatuan pada satu pengurangan biaya untuk sumber biaya. data Jadi pengembangan dapat dengan dan pemeliharaan sistem pada setiap departemen akan menghasilkan total biaya yang dikeluarkan akan lebih rendah. Sehingga sisa biaya yang merupakan penghematan sebelumnya dapat digunakan untuk hal lain yang dapat meningkatkan performa bagi kebutuhan organisasi. 15 16 9. Menyeimbangkan konflik kebutuhan Setiap pengguna mempunyai kebutuhan yang mungkin berbeda dengan kebutuhan pengguna lain. Oleh karena itu database dikendalikan oleh DBA (Database Administrator), DBA juga yang akan membuat keputusan berkaitan dengan perancangan dan penggunaan operasional database yang menyediakan penggunaan terbaik dari sumber daya bagi keseluruhan organisasi. 10. Meningkatkan kemampuan pengaksesan dan respon pada data Dengan mengintegrasikan data yang melintasi batasan departemen dapat langsung diakses oleh pengguna akhir, hal ini dapat menyediakan sebuah sistem dengan lebih banyak fungsi. 11. Meningkatkan produktivitas DBMS menyediakan banyak fungsi standar yang biasanya ditulis oleh programmer dalam aplikasi berbasis file. Pada tingkat menyediakan semua dasar, rutinitas DBMS juga tingkat rendah penanganan file yang khas dalam program aplikasi. Fungsi-fungsi ini memungkinkan seorang programmer untuk berkonsentrasi pada fungsi tertentu yang dibutuhkan oleh seorang pengguna. DBMS banyak juga menyediakan lingkungan generasi keempat, yang digunakan untuk menyederhanakan pengembangan aplikasi database. Hal ini menyebabkan produktivitas pemprogram meningkat dan waktu pengembangan berkurang (dengan penghematan biaya yang terkait). 12. Meningkatkan pemeliharaan melalui data independensi Dalam sistem berbasis file, deskripsi data dan logika untuk mengakses data yang dibangun ke dalam setiap program aplikasi, membuat program bergantung 17 pada data. Perubahan dengan cara data disimpan pada disk dapat memerlukan perubahan besar untuk program yang dipengaruhi oleh perubahannya. Sebaliknya, DBMS memisahkan deskripsi data dari aplikasi, sehingga membuat aplikasi kebal terhadap perubahan dalam deskripsi data. 13. Meningkatkan konkurensi DBMS juga digunakan untuk mengelola akses database secara bersamaan dan memastikan bahwa masalah seperti dua atau lebih pengguna yang diijinkan untuk mengakses file yang secara bersamaan akan mengakibatkan hilangnya informasi dan integritas. 14. Meningkatkan backup dan perbaikan layanan Backup data merupakan hal yang perlu diperhatikan karena untuk melindungi data dari kegagalan sistem. Backup harus sering dilakukan seiring dengan proses datanya dan apabila selama pekerjaan telah dipergunakan. terjadi kegagalan maka backup Dan DBMS modern memberikan fasilitas untuk meminimalkan jumlah pengolahan yang hilang setelah terjadi kegagalan. Setelah melihat keuntungan yang dimiliki DBMS, perlu melihat kerukurangan yang dimiliki oleh DBMS untuk dipertimbangkan. Menurut Connolly dan Begg (2010:80-81), kerugian dalam menggunakan DBMS ialah : 1. Kompleksitas Ketentuan dari fungsi yang diharapkan dari DBMS yang baik membuat DBMS menjadi sebuah software yang sangat kompleks, perancang dan pengembang database, DA, dan DBA, serta pengguna akhir harus memahami fungsi tersebut untuk mendapatkan banyak keuntungan dari DBMS tersebut. 18 19 2. Ukuran data yang besar Fungsi yang kompleks dan luas membuat DBMS menjadi software yang sangat besar, sehingga memerlukan banyak ruang harddisk dan jumlah memori yang digunakan menjadi sangat besar untuk berjalan dengan efisien. 3. Biaya dari DBMS Biaya DBMS bervariasi tergantung pada lingkungan dan fungsi yang disediakan. Padahal tersebut terdapat biaya pemeliharaan tahunan yang juga dimasukan dalam daftar harga DBMS. 4. Biaya penambahan perangkat keras Kebutuhan tempat penyimpanan bagi DBMS dan database sangat membutuhkan pembelian tempat penyimpanan tambahan lebih lanjut untuk mencapai performa yang diperlukan, dan akan membutuhkan spesifikasi perangkat keras yang lebih muktahir dan sebagainya yang memerlukan biaya yang tidak sedikit. Tergantung pada spesifikasi perangkat keras yang diperlukan. 5. Biaya konversi Di dalam situasi tertentu, biaya DBMS dan hardware tambahan mungkin relatif kecil biayanya dibandingkan dengan biaya mengkonversi aplikasi yang ada untuk berjalan di DBMS baru dan perangkat keras. Biaya ini juga termasuk biaya pelatihan karyawan untuk menggunakan sistem baru, dan mungkin kerja dengan karyawan spesialis untuk membantu dengan konversi dan menjalankan sistem. Biaya ini merupakan salah satu alasan utama mengapa beberapa organisasi merasa terikat pada sistem mereka saat ini. dan tidak bisa beralih ke teknologi database yang lebih modern. 20 21 6. Kinerja Kinerja DBMS secara umum sangat baik. Namun, DBMS ditulis lebih umum, untuk melayani banyak aplikasi bukan hanya satu. Hasilnya adalah bahwa beberapa aplikasi mungkin berjalan secepat dulu. Dan biasanya, sistem file-based ditulis untuk aplikasi tertentu seperti faktur. 7. Dampak kegagalan lebih besar Sumber daya terpusat akan meningkatkan kerentanan sistem. Karena semua pengguna dan aplikasi bergantung pada ketersediaan DBMS, sehingga apabila terjadi kegagalan komponen tertentu dapat membawa operasi berhenti. 22 2.1.4 Database Life Cycle Gambar 2.1 Database Lifecycle (Connolly dan Begg, 2010:314) 2.1.4.1 Database Planning Menurut Connolly dan Begg (2010:313), Database Planning adalah kegiatan manajemen yang memungkinkan tahapan siklus hidup sistem database untuk direalisasikan seefisien dan seefektif mungkin. 2.1.4.2 System Definition 23 Menurut Connolly dan Begg (2010:316), System Definition mendefinisikan perspektif sistem database berdasarkan ruang lingkup dan batasan dari aplikasi dan user views. 2.1.4.3 Requirement Collection and Analysis Menurut Requirement Connolly Collection dan and Begg Analysis (2010:316-320), adalahh proses pengumpulan dan analisis informasi tentang bagian dari organisasi yang akan didukung oleh sistem database, dan menggunakan informasi ini untuk mengidentifikasi persyaratan untuk sistem baru. 2.1.4.4 Database Design Menurut Connolly dan Begg (2010:320-325), Database Design adalah proses pembuatan desain yang akan mendukung mission statement dan mission objectives perusahaan untuk sistem database yang dibutuhkan. 2.1.4.5 DBMS (Database Management System) Selection Menurut Connolly dan Begg (2010:325-329), DBMS Selection adalah proses pemilihan DBMS yang tepat untuk mendukung sistem database. 2.1.4.6 Application Design Menurut Connolly dan Begg (2010:329-333), Application Design adalah desain user interface dan program aplikasi yang menggunakan dan memproses database. 2.1.4.7 Prototyping Menurut Connolly dan Begg (2010:333), Prototyping adalah proses pembuatan model kerja sementara untuk sistem database. Umumnya sebuah prototype merupakan sebuah 24 model kerja yang tidak memiliki semua fitur atau memberikan semua fungsi dari sistem. 2.1.4.8 Implementation Menurut Connolly dan Begg (2010:333-334), Implementasi adalah realisasi fisik dari database dan desain aplikasi. Implementasi database dapat dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih. 2.1.4.9 Data Conversion and Loading Menurut Connolly dan Begg (2010:334), Data Conversion and Loading adalah proses pemindahan beberapa data yang sudah ada ke dalam database baru dan mengubah aplikasi yang sudah ada untuk dapat dijalankan pada database yang baru. 2.1.4.10 Testing Menurut Connolly dan Begg (2010:334-335), Testing adalah proses untuk menjalankan program aplikasi dengan maksud menemukan dan mencari kesalahan-kesalahan. Sebelum digunakan, aplikasi database yang baru seharusnya telah melalui tahap percobaan. 2.1.4.11 Operational Maintenance Menurut Connolly dan Begg (2010:335-336), Operational Maintenance adalah sebuah proses pemantauan dan pemeliharaan terhadap sistem setelah di instalasi. 2.1.5 Metodologi Perancangan Database Menurut Connolly dan Begg (2010:466), terdapat tiga fase utama dalam metodologi perancangan basis data antara lain: 2.1.5.1 Perancangan Basis Data Konseptual 25 Perancangan basis data konseptual merupakan langkah pertama yang dilakukan dalam merancang sistem basis data. Pada langkah ini difokuskan pada pemodelan data konseptual perusahaan yang sama sekali tidak bergantung pada detil-detil implementasi. Perancangan basis data konseptual ini bertujuan untuk membangun model data konseptual dari kebutuhan data dari perusahaan. Model data konseptual terdiri dari: tipe entitas, tipe relasi, atribut dan domain atribut, primary key dan alternate key, dan batasan integritas. Model data konseptual juga didukung oleh dokumentasi, termasuk ER diagram dan kamus data yang dihasilkan melalui pengembangan model data konseptual. Seperti yang disampaikan oleh Woldemichael dan Hashim (2011:253), bahwa desain konseptual adalah proses pengetahuan intensif yang memerlukan beragam pengetahuan. Dengan demikian, permodelan harus mencakup sarana untuk menyimpan dan mengambil pengetahuan desain untuk meningkatkan pengetahuan mendesain. Proses desain konseptual dapat dianggap sebagai spesifikasi transformasi desain, yang diberikan sebagai persyaratan menjadi satu atau lebih konsep yang dapat memenuhi persyaratan untuk pengembangan lebih lanjut. Langkah- langkah yang dijalankan pada tahap ini: 1. Mengidentifikasi tipe entitas Pertama-tama dilakukan pengidentifikasian entitas dengan melihat objek-objek yang digunakan oleh user. Tujuannya adalah untuk mengidentifikasi entitas yang diperlukan. 2. Mengidentifikasi tipe relasi Tujuan identifikasi tipe relasi ini adalah untuk mengetahui relasi penting yang ada antara entitasentitas. Pada tahap ini, relasi digambarkan menggunakan ER Diagram untuk mempermudah dalam melihat relasi. 26 3. Mengidetifikasikan dan menghubungkan atribu-atribut dengan entitas atau relasi Pada langkah ini, ditentukan tipe-tipe fakta mengenai entitas dan relasi yang akan di masukkan ke dalam basis data. Tujuan langkah ini adalah untuk menghubungkan atribut-atribut dengan entitas atau relasi yang sesuai. 4. Menentukan atribut domain Menurut Connolly dan Begg (2010:477-478), Domain adalah sebuah kumpulan nilai-nilai dari satu atau lebih atribut yang diambil nilainya. Tujuan dari langkah ini adalah untuk menentukan domain untuk atribut-atribut pada model data konseptual. 5. Menentukan atribut candidate key, primary key, dan alternate key Tujuan dari langkah ini adalah untuk mengidentifikasi candidate key untuk setiap entitas dan, jika ada lebih dari satu candidate key, maka akan dipilih satu dari antara semua candidate key tersebut untuk menjadi primary key sementara sisanya menjadi alternate key. 6. Mempertimbangkan penggunaan konsep enhanced modeling (optional) Tujuan langkah ini adalah untuk mempertimbangkan penggunaan enhanced modeling, seperti spezialitation/generalization, aggregation, dan composition. 7. Melakukan pengecekan redudansi pada model Pada tahap ini, tujuannya adalah untuk melakukan pemeriksaan model data konseptual untuk menidentifikasi adanya redudansi dan menghilangkannya. 8. Menvalidasi model data konseptual terhadap transaksi user 27 Tujuan langkah ini adalah untuk memastikan bahwa model data konseptual yang dibuat mendukung kebutuhan transaksi. Untuk memastikan model data konseptual mendukung kebutuhan transaksi, ada dua pendekatan yang dapat digunakan: • Mendeskripsikan transaksi • Menggunakan transaction pathways 2.1.5.2 Perancangan Basis Data Logikal Tujuan utama dari perancangan basis data logikal ini adalah untuk menerjemahkan model data konseptual ke dalam model data logikal yang kemudian divalidasi untuk memeriksa benar tidaknya model data logikal secara struktural dan kemampuannya untuk mendukung kebutuhan transaksi. Langkah-langkah yang dijalankan pada tahap ini: 1. Mengambil relasi untuk model data logikal Tujuan dari langkah ini adalah untuk membuat relasi untuk model data logikal untuk mempresentasikan entitas, relasi, dan atribut yang telah di identifikasi. Dalam mendeskripsikan relasi yang diambil, berikut relasi yang mungkin terjadi: • Tipe entitas kuat Menurut Connolly dan Begg (2010:492), Entitas kuat adalah entitas yang keberadaannya tidak bergantung pada keberadaan entitas lainnya. Dimana pada entitas ini mempunyai karakter bahwa setiap kejadian entitas teridentifikasi secara unik yang memiliki atribut primary key yang dapat membedakan dari entitas yang lain. • Tipe entitas lemah Menurut Connolly dan Begg (2010:492-493), Sedangkan tipe entitas lemah 28 merupakan entitas yang keberadaanya tergantung oleh beberapa entitas yang lain. Pada entitas ini, karakteristik yang dimilikinya ialah setiap kejadian entitas tidak dapat teridentifikasi secara unik hanya dengan menggunakan atribut entitas tersebut, tidak seperti halnya tipe entitas kuat yang menggunakan primary key. • One-to-many (1:*) tipe relasi binary Menurut Connolly dan Begg (2010:493), Kondisi ini terjadi apabila tiap anggota pada entitas pertama mempunyai pasangan dengan lebih dari satu anggota entitas kedua. • One-to-one (1:1) tipe relasi binary Menurut Connolly dan Begg (2010:493-495), Pada tipe relasi ini dapat terjadi apabila tiap anggota pada entitas Client hanya dapat berpasangan dengan satu anggota dari entitas Preference. Demikian sebaliknya tiap entitas Preference juga hanya dapat berpasangan dengan satu anggota dari entitas Client. • One-to-one (1:1) tipe relasi rekursif • Superclass/subclass relationship types • Many-to-many (*:*) tipe relasi binary Pada hubungan antar entitas ini akan terjadi apabila kedua anggota entitas tersebut dapat berpasangan lebih dari satu anggota entitas. • Tipe relasi yang komplek Relasi yang komplek adalah jumlah dari suatu kejadian yang mungkin dari suatu 29 entitas dalam n-ary relationship ketika nilai entitas yang lain (n-1) diketahui. • Atribut multi-valued 2. Validasi relasi menggunakan normalisasi Tujuan langkah ini adalah untuk melakukan validasi model data logikal menggunakan normalisasi. Tujuan dari normalisasi ini adalah untuk memastikan set dari relasi mempunyai sejumlah atribut yang minimal namun cukup yang diperlukan untuk mendukung kebutuhan data perusahaan. 3. Validasi relasi terhadap transaksi user Tujuan langkah ini adalah untuk memastikan relasi model data logikal yang dibuat mendukung kebutuhan transaksi, secara detil seperti yang dispesifikasikan pada kebutuhan user. 4. Mendefinisikan batasan integritas Tujuan langkah ini adalah untuk memeriksa apakah batasan integritas ditampilkan dalam model data logikal. Batasan integritas ini bertujuan untuk melindungi basis data dari ketidak lengkapan, ketidak akuratan, atau ketidak konsistenan. Berikut adalah beberapa tipe batasan integritas: • Required data Beberapa atribut harus memiliki isi pada datanya sehingga tidak diperbolehkan menerima null. • Attribute domain constraints Masing-masing atribut memiliki domain yang merupakan sekumpulan nilai yang sah. • Multiplicity • Entity integrity Dimana primary key dari sebuah entitas tidak dapat bernilai null. 30 • Referential integrity Bila foreign key mempunyai nilai, maka nilai tersebut haruslah menunjuk pada tuple yang ada pada relasi induk. Untuk melakukan itu, referential integrity existence constraints perlu dispesifikasikan yang mendefinisikan kondisi dimana sebuah candidate key atau foreign key ditambahkan, diubah, atau di hapus. Jika terdapat sebuah tuple dari relasi induk dihapus, maka referential integrity akan hilang apabila adanya tuple anak menunjuk ke tuple induk yang dihapus. Ada beberapa cara yang dapat digunakan: a. No Action Strategi yang digunakan ialah mencegah penghapusan dari relasi induk jika terdapat refrensi ke tuple anak. b. Cascade Apabila pada tuple induk dihapus, maka secara otomatis tuple anak akan dihapus juga. c. Set Null Jika pada tuple induk dihapus, maka nilai foreign key pada semua tuple anak otomatis akan terisi nilai null. d. Set Default Jika pada tuple induk dihapus, maka foreign key pada semua tuple akan menerima nilai default. e. No Check Jika tuple induk dihapus, maka tidak dilakukan apapun untuk meyakinkan bahwa referential integrity terjaga. 5. Melakukan review model data logikal dengan user 31 Tujuan langkah ini adalah untuk melakukan review bersama user untuk memastikan user mempertimbangkan model yang telah dibuat sesuai dengan kebutuhan data perusahaan. 6. Menggabungkan model data logikal menjadi model global (optional) Tujuan dari langkah ini adalah untuk menggabungkan model data logikal menjadi data logikal global tunggal yang menampilkan semua user views dari basis data. 7. Melakukan pemeriksaan untuk perkembangan di masa datang Tujuan langkah ini adalah untuk menentukan apakah ada perubahan yang signifikan di masa mendatang dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan-perubahan tersebut. 2.1.5.3 Perancangan Basis Data Fisikal Dalam proses perancangan basis data fisikal, akan dihasilkan deskripsi implementasi dari basis data pada secondary storage. Perancangan basis data fisikal akan mendeskripsikan basis relasi, file organisasi dan index yang digunakan untuk mencapai akses data yang efisien dan segala batasan integritas yang terkait dan masalah sekuritas. Langkah-langkah yang dijalankan pada tahap ini: 1. Menerjemahkan model data logikal untuk target DBMS Tujuan langkah ini adalah untuk menghasilkan skema relasi basis data dari model data logikal yang dapat diimplementasikan pada target DBMS. Untuk menjalankan tahap ini, terbagi menjadi tiga langkah sebagai berikut. • Merancang relasi dasar (base relation) 32 Pada langkah ini, hal pertama yang dilakukan adalah pengumpulan dan pemahaman informasi tentang relasi yang telah dihasilkan selama perancangan logikal basis data. Setelah itu, menentukan bagaimana mempresentasikan relasi dasar pada target DBMS. Setiap relasi yang diidentifikasikan dalam model data logikal memiliki definisi yang terdiri dari: nama relasi, daftar atribut sederhana, primary key, alternate keys, dan foreign keys, dan referensial integritas batasan untuk setiap foreign keys yang diidentifikasi. • Merancang representasi dari data yang diambil Tujuan menentukan langkah ini adalah bagaimana untuk mempresentasikan data yang diambil dari data yang ada di dalam model data logikal pada target DBMS. • Merancang batasan umum Tujuan langkah ini adalah untuk merancang batasan umum untuk target DBMS. 2. Merancang file organisasi dan index Tujuan langkah ini adalah untuk menentukan file organisasi yang optimal untuk menyimpan relasi dasar dan index yang diperlukan untuk mencapai kinerja yang sesuai, yaitu bagaimana jalan dari relasi dan tuple dapat disimpan dalam secondary storage. Tahap ini dibagi menjadi empat langkah, yaitu: • Menganalisa transaksi Tujuan langkah ini adalah untuk memahami transaksi secara fungsional yang akan dijalankan dalam basis data dan untuk menganalisa transaksi yang penting. Untuk membantu mengidentifikasi transaksi mana yang perlu diteliti, dapat menggunakan 33 transaction relation cross-reference matrix yang menunjukkan relasi setiap akses tranasaksi. Untuk fokus pada area yang mungkin bermasalah, salah satu cara untuk melanjutkan: a. Map seluruh jalan transaksi untuk relasi. b. Tentukan relasi mana yang sering diakses oleh transaksi. c. Analisa penggunaan data dari transaksi yang dipilih yang melibatkan transaksitransaksi lain. • Memilih file organisasi Tujuan langkah ini adalah untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. • Memilih index Tujuan langkah ini adalah untuk menentukan apakah penambahan index akan meningkatkan kinerja dari sistem. • Memperkirakan kapasitas disk yang diperlukan Tujuan langkah ini adalah untuk memperkirakan jumlah kapasitas disk yang akan diperlukan oleh basis data sehingga dapat diperkirakan penggunaan kapasitas disk setiap tahunnya. 3. Merancang user views Tujuan langkah ini adalah untuk merancang user views yang diidentifikasi selama pengumpulan kebutuhan dan analisa tahap dari pengembangan siklus kehidupan sistem basis data. 4. Merancang mekanisme security Tujuan langkah ini adalah untuk merancang mekanisme security untuk basis data seperti yang telah dispesifikasikan oleh user selama tahap 34 pengumpulan dan analisa kebutuhan dari pengembangan siklus kehidupan sistem basis data. 2.1.6 ERD (Entity-Relationship Diagram) Menurut Whitten dan Bentley (2007:271), ERD (Entity Relationship Diagram) adalah model data yang menggunakan beberapa notasi untuk menggambarkan data dalam konteks entitas dan hubungan yang dideskripsikan oleh data tersebut. ERD digunakan untuk memodelkan struktur data dan hubungan antar data. Dengan ERD, model dapat diuji dengan mengabaikan proses yang dilakukan. Tabel 2.1 Tabel Notasi dalam ERD (Whitten dan Bentley, 2007:273) Notasi Keterangan Entitas adalah suatu objek yang dapat di identifikasi dalam lingkungan pemakai. Relasi menunjukkan adanya hubungan di antara sejumlah entitas yang berbeda. Atribut berfungsi mendeskripsikan karakter entitas (atribut yang berfungsi sebagai key diberi garis bawah). Garis sebagai penghubung antara relasi dengan entitas, relasi, dan entitas dengan atribut. 2.1.7 Kardinalitas Relasi 35 Menurut Whitten dan Bentley (2007:276), dalam ERD hubungan (relasi) dapat terdiri dari sejumlah entitas yang disebut dengan derajat relasi. Derajat relasi maksimum disebut dengan kardinalitas sedangkan derajat minimum disebut dengan modalitas. Jadi kardinalitas relasi menunjukkan jumlah maksimum entitas yang dapat berelasi dengan entitas pada himpunan entitas lain. a. One to One Relationship Hubungan antara file pertama dan file kedua adalah satu berbanding satu. Contoh: Pada pengajaran private satu guru satu siswa. “Seorang guru mengajar seorang siswa, seorang siswa diajar oleh seorang guru”. Gambar 2.2 Entitas One to One Relationship b. One to Many atau Many to One Relationship Hubungan antara file pertama dan file kedua adalah satu berbanding banyak atau banyak berbanding satu. Contoh: Dalam suatu perusahan satu bagian mempekerjakan banyak pegawai. “Satu bagian mempekerjakan banyak pegawai, satu pegawai kerja dalam satu bagian”. Gambar 2.3 Entitas Many to One Relationship c. Many to Many Relationship Hubungan file pertama dan file kedua adalah banyak berbanding banyak. 36 Contoh: Dalam universitas seorang mahasiswa dapat mengambil banyak mata kuliah. “Satu mahasiswa mengambil banyak matakulih dan satu matakuliah diambil banyak mahasiswa.” Gambar 2.4 Entitas Many to Many Relationship 2.1.8 Langkah-Langkah Perancangan Teknik Entity-Relationship Menurut Connolly dan Begg (2010:364), sumber awal data teknik perencanaan database dengan ER adalah data dictionary (kumpulan data). Langkah-langkah perancangan ER: 1. Memilih kelompok atribut yang sama untuk dijadikan sebuah entitas dan menentukan primary key dengan syarat unik dan mewakili entitas. 2. Menggambarkan Cardinality dari ER diagram berdasarkan analisa relasi yang didapat. Relasi yang terjadi dapat one to one, one to manY dan many to many relationship. 3. Membentuk Skema Database atau LRS (Logical Record Structure) berdasarkan ER diagram. Keterangan: • Bila relasi one to one maka foreign key diletakkan pada salah satu dari dua entitas yang ada atau menyatukan ke dua entitas tersebut. • Bila relasi one to many maka foreign key diletakkan di entitas yang Many. • Bila relasi many to many maka dibuat “file konektor” yang berisi 2 foreign key yang berasal dari kedua entitas. • Membentuk tabel-tabel berdasarkan primary key yang terpilih dengan syarat sudah mencapai aturan normalisasi sekurangkurangnya 3NF dari Skema DB/LRS yang ada. 37 2.1.9 Normalisasi Menurut Connolly dan Begg (2010:416-417), normalisasi merupakan sebuah teknik untuk memproduksi satu set hubungan dengan sifat yang diinginkan, memberikan kebutuhan data pada perusahaan. Proses Normalisasi antara lain: • Suatu teknik formal untuk menganalisis relasi berdasarkan primary key dan fungsi dependensi antar atribut yang ada. • Di eksekusi dalam beberapa cara. Setiap cara mengacu ke bentuk normal tertentu, sesuai dengan sifat yang dimilikinya. • Setelah Normalisasi diproses, relasi akan secara bertahap lebih terbatas/kuat bentuk formatnya dan juga mengurangi tindakan anomali pada setiap update. Bentuk-bentuk normalisasi menurut Connolly dan Begg (2010:428-455), antara lain: 1. Unnormalized Form (UNF) Merupakan sebuah tabel awal yang belum ternormalisasi yang berisikan satu atau lebih kumpulan data yang berulang. Untuk membuat tabel UNF yaitu dengan memindahkan data dari sumber informasi yang di dapat ke dalam tabel dengan format baris dan kolom, jika ada atribut yang mempunyai banyak nilai (multivalue) akan masuk ke dalam bentuk UNF. 2. First Normal Form (1NF) Bentuk normalisasi tahap pertama yang merupakan sebuah relasi dimana sebuah titik pertemuan antara setiap baris dan kolom yang berisi satu dan hanya satu nilai. 3. Second Normal Form (2NF) Tahapan kedua setelah 1NF terpenuhi yaitu 2NF dimana merupakan sebuah relasi yang terdapat di dalam 1NF dan setiap atribut yang bukan primary key bergantung pada primary key. 4. Third Normal Form (3NF) 38 Merupakan tahapan ketiga dalam normalisasi dimana sebuah relasi yang terdapat pada bentuk normalisasi pertama dan kedua, yang mana atribut primary key bergantung pada primary key. 2.1.10 Teori Waterfall Gambar 2.5 Fase-Fase Model Teori Waterfall (Pressman, 2010:39) 1. Communication Langkah ini merupakan analisis terhadap kebutuhan software, dan tahap untuk mengadakan pengumpulan data dengan melakukan pertemuan dengan customer, maupun mengumpulkan data-data tambahan baik yang ada di jurnal, artikel, maupun dari internet. 2. Planning Proses planning merupakan lanjutan dari proses communication (analysis requirement). Tahapan ini akan menghasilkan dokumen user requirement atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan software, termasuk rencana yang akan dilakukan. 3. Modeling Proses modeling ini akan menerjemahkan syarat kebutuhan ke sebuah perancangan software yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada rancangan struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirement. 4. Construction 39 Construction merupakan proses membuat kode. Coding atau pengkodean merupakan penerjemahan desain dalam bahasa yang bisa dikenali oleh komputer. Programmer akan menerjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu software, artinya penggunaan komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap sistem tersebut untuk kemudian bisa diperbaiki. 5. Deployment Tahapan ini bisa dikatakan final dalam pembuatan sebuah software atau sistem. Setelah melakukan analisis, desain dan pengkodean maka sistem yang sudah jadi akan digunakan oleh user. Kemudian software yang telah dibuat harus dilakukan pemeliharaan secara berkala. 2.1.11 Tools yang digunakan 2.1.11.1 UML (Unified Modelling Language) Menurut Whitten & Bentley (2007:371), UML (Unified Modelling Language) adalah suatu metode yang digunakan untuk menentukan dan menggambarkan sistem piranti lunak dari segi objek orientasinya. UML tidak menentukan metode untuk mengembangkan sistem, tetapi hanya membuat notasi yang sekarang dikenal secara luas dan diakui sebagai standar untuk pemodelan objek. 2.1.11.1.1 Diagram Use Case Menurut Sommerville (2011:124), diagram Use Case merupakan sebuah diagram yang menunjukkan interaksi antara sistem dan lingkungan. Setiap diagram 40 use case merepresentasikan tugas yang berlainan yang melibatkan hubungan antara lingkungan dengan sistem. Dalam bentuk yang paling sederhana, kasus penggunaan ditunjukkan sebagai elips dengan aktor. Menurut Whitten dan Bentley (2007:382), diagram Use Case menggambarkan fungsi sistem dari perspektif pengguna dengan cara dan terminologi mereka mengerti. Untuk akurat dan benar-benar mencapai hal ini, use case menuntut tingkat tinggi keterlibatan pengguna dan ahli subjek-materi yang memiliki pengetahuan tentang proses bisnis atau acara. Diagram Use Case dekat kaitannya dengan kejadian-kejadian. Kejadian (scenario) merupakan contoh apa yang terjadi ketika seseorang berinteraksi dengan sistem. 41 Tabel 2.2 Tabel Simbol pada Diagram Use Case (Whitten dan Bentley, 2007:246248) No Gambar Nama Fungsi Simbol 1 Aktor Aktor adalah segala sesuatu yang berinteraksi dengan sistem untuk melakukan pertukaran informasi.Aktor umumnya mempresentasikan interaksi antara manusia dengan sistem dimana aktor merupakan manusia tetapi dapat juga digunakan untuk merepresentasikan perangkat eksternal. 2 Use Case Use case digunakan untuk menjelaskan fungsi dari sistem yang merepresentasikan tujuan dari sistem dan mendeskripsikan aktivitas dan interaksi user dengan sistem untuk mencapai tujuan tersebut. 3 Hubungan Menggambarkan hubungan antara dua simbol pada use case diagram,misalnya hubungan antara aktor dengan use case. 4 Sistem Sistem ialah tempat untuk menaruh setiap kerja yang dilakukan dan menjadi tempat terjadinya seluruh aktivitas. 42 Gambar 2.6 Diagram Use Case Hubungan Aktor dengan Kejadian (Whitten dan Bentley, 2007:246) 2.1.11.1.2 Diagram Class Menurut Sommerville (2011:129), diagram class digunakan pada saat perancangan model sistem yang berorientasi objek untuk menunjukkan kelas objek yang ada di dalam sistem dan hubungan dari kelaskelas yang ada. Diagram class pada UML dapat di implementasikan pada beberapa gambaran yang detail. Ketika perancangan suatu model, tahap awal ialah melihat pada dunia asli, kemudian menentukan objekobjek yang dianggap penting dan mempresentasikannya sebagai suatu kelas. Ketika menggambarkan hubungan antar kelas maka perlu diberikan penjelasan yang jelas di setiap kelasnya. Menurut Whitten dan Bentley (2007:382), diagram class menggambarkan struktur dari suatu objek sistem yang menunjukkan bahwa sistem ini 43 terdiri atas hubungan antar kelas objek. Berikut ini merupakan penjelasan tentang tabel asosiasi diagram class. Tabel 2.3 Tabel Asosiasi Diagram Class (Whitten dan Bentley, 2007:377) 44 Gambar 2.7 Diagram Class Produk (Whitten dan Bentley, 2007:404) 2.1.11.1.3 Diagram Activity Menurut Whitten & Bentley (2007:382), diagram activity menggambarkan urutan aliran kegiatan kasus atau prosesbisnis. Diagram activity juga dapat digunakan untuk model logika dengan sistem. Dalam diagram activity terdapat beberapa simbol yang digunakan untuk menerangkan proses dalam sistem, yaitu: 45 Tabel 2.4 Tabel Simbol pada Diagram Activity (Whitten dan Bentley, 2007:391) No Gambar Nama Simbol 1 Initial Node 2 Actions Deskripsi Menunjukkan awal dari suatu proses. Menunjukkan langkah-langkah aktivitas sistem yang terjadi 3 Flow Untuk menunjuk ke aksi atau proses yang lain dan dilengkapi dengan kata-kata jika berasal dari decision. 4 Decision Memiliki sebuah flow masuk dan dua atau lebih flow keluar. Menunjukkan aktivitas yang dapat dipilih. 5 Merge Menyatukan flow yang sebelumnya terpisah oleh decision. 6 Fork Menotasikan permulaan aksi atau proses paralel yang dapat terjadi dalam suatu urutan atau terjadi secara bersamaan. 7 Join Semua aksi yang masuk ke join harus telah diselesaikan sebelum proses berlanjut. 8 Activity Final Menunjukkan akhir dari suatu proses 46 Gambar 2.8 Diagram Activity Melakukan Input Member Baru (Whitten dan Bentley, 2007:392) 2.1.11.2 STD (State Transition Diagram) 47 State Transition Diagram (STD) adalah diagram yang digunakan untuk menggambarkan suatu proses dihubungkan antara satu dengan yang lain dalam waktu yang bersamaan. STD terdiri dari notasi state dan transition state. Masingmasing notasi terdiri atas kejadian (sistem) dan aksi (user). • Keadaan • Perubahan keadaan 2.1.11.3 DFD (Data Flow Diagram) Menurut Jogiyanto Hartono (2005:701), DFD (Data Flow Diagram) adalah diagram yang menggunakan notasi simbol untuk menggambarkan arus data sistem. DFD sering digunakan untuk menggambarkan suatu sistem yang telah ada atau sistem yang baru yang akan dikembangkan secara logika dan menjelaskan arus data dari mulai pemasukan sampai dengan keluaran data tingkatan diagram arus data mulai dari diagram konteks yang menjelaskan secara umum suatu sistem atau batasan sistem dari level 0 dikembangkan menjadi level 1 sampai sistem tergambarkan secara rinci. Gambaran ini tidak tergantung pada perangkat keras, perangkat lunak, struktur data atau organisasi file. 1. Kesatuan Luar (External Entity) Kesatuan luar (external entity) merupakan kesatuan (entity) di lingkungan luar sistem yang dapat berupa orang, organisasi, atau sistem lain yang berada pada lingkungan luarnya yang memberikan input atau menerima output dari sistem. 48 2. Arus Data (Data Flow) Kesatuan luar (external entity) merupakan kesatuan (entity) di lingkungan luar sistem yang dapat berupa orang, organisasi, atau sistem lain yang berada pada lingkungan luarnya yang memberikan input atau menerima output dari sistem. 3. Proses (Process) Proses (process) menunjukan pada bagian yang mengubah input menjadi output, yaitu menunjukan bagaimana satu atau lebih input diubah menjadi beberapa output. Setiap proses mempunyai nama, nama dari proses ini menunjukan apa yang dikerjakan proses. 4. Simpanan Data (Data Store) Data Store merupakan simpanan dari data yang dapat berupa suatu file atau database pada sistem komputer. Istilah data flow diagram bertingkat (leveled DFD) digunakan untuk menggambarkan hirarki dari berbagai diagram, yang digunakan untuk mendokumentasikan suatu sistem. a. Diagram Nol (Zero) Diagram Nol (Zero) adalah diagram tingkat menengah yang menggambarkan proses-proses utama 49 dalam sistem, yang terdiri dari sistem, hubungan entity, proses, data flow dan data store. b. Diagram Konteks Diagram Konteks adalah diagram yang terdiri dari proses dan menggambarkan hubungan terminator dengan sistem yang mewakili suatu proses. 2.1.11.4 Delapan Golden Rules Menurut Shneiderman (2010:88-89), dalam merancang antarmuka pengguna (interaksi manusia dan komputer) membutuhkan 8 prinsip yang diaplikasikan hampir di semua sistem interaktif dan biasanya disebut Golden Rules. Berikut adalah kedelapan Golden Rules tersebut: 1. Berusaha untuk tetap konsisten (strive for consistency) Konsistensi harus dilakukan pada setiap urutan tindakan, perintah, menu, layar bantuan, penggunaan warna, kapitalisasi, fonts, dan sebagainya kecuali pada tampilan untuk konfirmasi erintah menghapus. 2. Menyediakan penggunaan secara universal (cater to universal usability) Menyediakan fitur untuk pemula, juga menyediakan fitur seperti tombol cepat (shortcut) untuk pengguna expert agar mempermudah dan mempercepat aksi, selain itu juga untuk meningkatkan kualitas sistem. 3. Memberikan umpan balik yang informatif (offer informative feedback) Suatu sistem umpan balik (feedback) harus diperhitungkan untuk setiap tindakan dari pengguna. Untuk tindakan yang sering dilakukan dan tidak terlalu penting, cukup diberi umpan balik yang 50 sederhana saja. Namun jika sebaliknya, maka umpan balik yang diberikan sebaiknya lebih substansial. 4. Merancang dialog pada keadaan akhir (design dialogs to yields closure) Urutan tindakan harus disusun kedalam suatu kelompok dengan bagian awal, tengah, dan akhir. Suatu umpan balik yang informatif sebaiknya dibuat pada akhir tindakan untuk memberikan indikasi bahwa cara yang dilakukan sudah benar atau tindakan tersebut telah selesai dan siap untuk melanjutkan ke tindakan berikutnya. 5. Memberikan pencegahan dan penanganan kesalahan yang sederhana (prevent errors) Sistem yang dibuat diharapkan tidak menghasilkan kesalahan yang serius saat digunakan oleh pengguna. Jika pengguna melakukan kesalahan, sistem harus dapat mendeteksi kesalahan pengguna dan menawarkan solusi sederhana serta instruksi yang spesifik untuk melakukan recovery. 6. Memungkinkan pembalikan aksi yang mudah (permit easy reversal of actions) Diharapkan adanya fitur untuk kembali (back) ke aktivitas sebelumnya. Hal ini dapat mengurangi kekuatiran pengguna karena pengguna mengetahui kesalahan yang telah dilakukan dapat dibatalkan, sehingga mendorong pengguna untuk mengeksplorasi pilihan-pilihan lain yang belum biasa digunakan. 7. Mendukung pusat kendali internal (support internat locus of control) Pada berpengalaman umumnya, pengguna yang memiliki keinginan untuk mengendalikan antarmuka sistem secara penuh, maka sepatutnya sistem harus dapat merespon 51 tindakan yang dilakukan pengguna dengan baik. Sebaiknya sistem dirancang sedemikian rupa sehingga pengguna menjadi inisiator daripada responden. 8. Mengurangi beban ingatan jangka pendek (reduce short-term memory load) Karena keterbatasan ingatan manusia untuk memproses informasi dalam jangka pendek, maka harus dihindari keadaan dimana pengguna diharuskan mengingat suatu informasi di suatu layar dan diharuskan menggunakan informasi tersebut di layar yang berbeda serta diberikan cukup waktu untuk mempelajari kode, mnemonic, dan urutan tindakan. 2.1.11.5 PHP (Hypertext Prepocessor) Menurut Anhar (2010:3), PHP (Hypertext Prepocessor) adalah bahasa server-side scripting yang menyatu dengan HTML untuk membuat halaman web yang dinamis. Dinamis berarti halaman yang akan ditampilkan dibuat saat halaman itu diminta oleh client. Mekanisme ini menyebabkan informasi yang diterima client selalu yang terbaru. Semua script PHP diesksekusi pada server dimana script tersebut dijalankan. 2.1.11.6 MySQL (Structured Query Language) Menurut Anhar (2010:45), MySQL (My structure Query Language) adalah salah satu database management system (DBMS) dari sekian banyak DBMS seperti Oracle, MS SQL, postagre SQL, dan lainnya. My SQL berfungsi untuk mengolah data base menggunakan bahasa SQL. MySQL bersifat open source sehingga kita bisa menggunakanya secara gratis. Pemrograman PHP juga sangat mendukung/support dengan database MySQL. 52 2.2 Teori yang Berkaitan dengan Tema 2.2.1 Pembelian Pembelian didefinisikan sebagai usaha untuk memenuhi kebutuhan atas barang atau jasa yang diperlukan oleh perusahaan dan dapat diterima tepat pada waktunya dengan mutu yang sesuai serta harga yang menguntungkan. a. Saat pemesanan Saat pemesanan sangatlah tergantung pada kualitas barang yang masih ada, rata-rata tingkat pemakaiannya dan jangka waktu pemesanan. b. Jumlah yang dipesan Jumlah yang dipesan ditetapkan secara matematis dan juga menurut kebijaksanaan untuk medapatkan kuantitas pesanan-pesanan ekonomis. c. Rekanan Dalam menetapkan pilihan rekanan mesti dikaitkan pada harga, syarat pembayaran, kualitas keandalan lokasi saat penyerahan yang dijanjikan. Menurut Mulyadi (2010:299), pembelian adalah suatu usaha yang dilakukan untuk pengadaan barang yang diperlukan oleh perusahaan. Jenis pembelian berdasarkan pemasok: 1. Pembelian lokal adalah pembelian dari pemasok yang berasal dari dalam negeri. 2. Pembelian impor adalah pembelian dari pemasok yang berasal dari luar negeri. Jenis pembelian berdasarkan transaksi: 1. Transaksi pembelian tunai adalah jenis transaksi dimana pembayarannya dilakukan secara langsung pada saat barang diterima. 2. Transaksi pembelian kredit adalah jenis transaksi dimana pembayarannya tidak dilakukan secara langsung pada 53 saat barang diterima, tetapi dilakukan selang beberapa waktu setelah barang diterima, sesuai perjanjian kedua belah pihak. Menurut Mulyadi (2010:299), fungsi yang terkait dalam sistem akuntansi pembelian adalah: 1. Fungsi gudang Fungsi gudang bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. Untuk barang-barang yang langsung dipakai (tidak diselenggarakan persediaan barang di gudang), permintaan pembelian diajukan oleh pemakai barang. 2. Fungsi pembelian Fungsi pembelian bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, mendapatkan informasi mengenai permintaan pembelian dari gudang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. 3. Fungsi penerimaan Fungsi penerimaan bertanggungjawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima pemasok bertujuan untuk menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan. Fungsi ini juga bertanggungjawab untuk menerima barang dari pembeli yang berasal dari transaksi retur penjualan. 4. Fungsi akuntansi Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat hutang dan fungsi pencatat persediaan. Fungsi pencatat hutang bertanggungjawab untuk mencatat transaksi pembelian ke dalam register bukti kas keluar dan untuk menyelenggarakan arsip dokumen sumber (bukti kas keluar) yang berfungsi sebagai catatan hutang atau menyelenggarakan kartu hutang sebagai buku pembantu hutang. Fungsi pencatat persediaan 54 bertanggung jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan. Menurut Mulyadi (2010:301), jaringan prosedur dalam sistem pembelian adalah: 1. Prosedur permintaan pembelian Dalam prosedur ini, fungsi gudang mengajukan permintaan pembelian dalam formulir surat permintaan pembelian kepada fungsi pembelian. Surat tersebut berisi sejumlah jenis barang-barang yang akan dibeli dan dibuat dalam beberapa rangkap. Permintaan pembelian tersebut akan dipenuhi tergantung dari keputusan manager perusahaan yang bersangkutan. 2. Prosedur permintaan penawaran harga dan pemilihan pemasok Dalam prosedur ini, fungsi pembelian mengirimkan surat permintaan penawaran harga kepada para pemasok untuk memperoleh informasi mengenai harga barang dan berbagai syarat pembelian yang lain untuk memungkinkan pemilihan pemasok yang akan ditunjuk sebagai pemasok barang yang diperlukan oleh perusahaan. 3. Prosedur order pembelian Dalam prosedur ini, fungsi pembelian mengirim surat order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit-unit organisasi lain dalam perusahaan mengenai order pembelian yang telah dikeluarkan oleh perusahaan. 4. Prosedur penerimaan barang Dalam prosedur ini, fungsi penerimaan barang melakukan pemeriksaan mengenai jenis, kuantitas, dan mutu barang yang diterima dari pemasok dan kemudian membuat laporan penerimaan barang untuk menyatakan penerimaan barang dari pemasok tersebut. 5. Prosedur distribusi pembelian Prosedur ini meliputi distribusi rekening yang di debit dari transaksi pembelian manajemen. untuk kepentingan pembuatan laporan 55 Retur Pembelian Menurut Mulyadi (2010:335), sistem retur pembelian digunakan dalam perusahaan untuk pengembalian barang yang sudah dibeli kepada pemasoknya. Barang yang sudah diterima pemasok terkadang tidak sesuai dengan barang yang dipesan menurut surat order pembelian. Ketidaksesuaian itu terjadi kemungkinan karena barang yang diterima tidak cocok dengan spesifikasi yang tercantum dalam surat order pembelian, barang mengalami kerusakan dalam pengiriman, atau barang yang diterima melewati tanggal pengiriman yang dijanjikan oleh pemasok. Fungsi terkait dalam sistem retur pembelian adalah: 1. Fungsi gudang Fungsi gudang bertanggung jawab untuk menyerahkan barang kepada fungsi pengiriman seperti yang tercantum dalam tembusan memo debit yang diterima dari fungsi pembelian. 2. Fungsi pembelian Fungsi pembelian bertanggung jawab untuk mengeluarkan memo debit untuk retur pembelian. 3. Fungsi pengiriman Fungsi pengiriman bertanggung jawab untuk mengirimkan kembali barang kepada pemasok sesuai dengan perintah retur pembelian dalam memo debit yang diterima dari fungsi pembelian. 4. Fungsi akuntansi Fungsi akuntansi bertanggung jawab untuk mencatat transaksi retur pembelian dalam jurnal retur pembelian atau jurnal umum, mencatat berkurangnya harga pokok persediaan karena retur pembelian dalam kartu persediaan, dan mencatat berkurangnya hutang yang timbul dari transaksi retur pembelian dalam arsip bukti kas keluar yang belum dibayar atau dalam kartu hutang. Menurut Mulyadi (2010:339), sistem retur pembelian terdiri dari jaringan prosedur berikut ini: 1. Prosedur perintah retur pembelian 56 Dalam prosedur ini, retur pembelian terjadi atas perintah fungsi pembelian kepada fungsi pengiriman untuk mengirimkan kembali barang yang telah diterima oleh fungsi penerimaan kepada pemasok yang bersangkutan. Dokumen yang digunakan oleh fungsi pembelian untuk memerintahkan fungsi pengiriman mengembalikan barang ke pemasok adalah memo debit. 2. Prosedur pengiriman barang ke pemasok Dalam prosedur ini, fungsi pengiriman barang kepada pemasok sesuai dengan perintah retur pembelian yang tercantum dalam memo debit dan membuat laporan pengiriman barang untuk transaksi retur pembelian tersebut. 3. Prosedur pencatatan hutang Dalam prosedur ini, fungsi akuntansi memeriksa dokumendokumen yang berhubungan dengan retur pembelian dan menyelenggarakan pencatatan berkurangnya hutang dalam kartu hutang atau mengarsipkan dokumen memo debit sebagai pengurang hutang. 2.2.2 Penjualan Penjualan merupakan kegiatan yang dilakukan oleh penjual dalam menjual barang atau jasa dengan harapan akan memperoleh laba dari adanya transaksi-transaksi tersebut dan penjualan dapat diartikan sebagai pengalihan atau pemindahan hak kepemilikan atas barang atau jasa dari pihak penjual ke pembeli. Secara umum penjualan pada dasarnya terdiri dari dua jenis yaitu penjualan tunai dan kredit. Penjualan tunai terjadi apabila penyerahan barang atau jasa segera diikuti dengan pembayaran dari pembelian, sedangkan penjualan kredit ada tenggang waktu antara saat penyerahan barang atau jasa dalam penerimaan pembelian. Keuntungan dari penjualan tunai adalah hasil dari penjualan tersebut langsung terealisir dalam bentuk kas yang dibutuhkan perusahaan untuk mempertahankan likuiditasnya. Sedangkan dalam rangka memperbesar volume penjualan, umumnya perusahaan menjual produknya secara kredit. Penjualan kredit tidak segera 57 menghasilkan pendapatan kas, tapi kemudian menimbulkan piutang. Kerugian dari penjualan kredit adalah timbulnya biaya administrasi piutang dan kerugian akibat piutang tak tertagih. Perancangan Sistem Informasi Akuntansi Penjualan Beberapa fungsi yang terkait dalam prosedur penjualan adalah sebagai berikut: 1. Fungsi Kas Fungsi ini bertanggungjawab sebagai penerima kas dari pembeli. 2. Fungsi Gudang Fungsi gudang berfungsi untuk menyediakan barang yang diperlukan oleh pelanggan sesuai dengan yang tercantum dalam tembusan faktur penjualan yang diterima dari fungsi penjualan. 3. Fungsi Akuntansi Fungsi ini bertanggungjawab sebagai pencatat transaksi penjualan dan penerimaan kas dan pembuatan laporan penjualan. 2.2.3 Persediaan Barang Barang dagangan dalam perusahaan disebut dengan persediaan barang dagangan atau kadang-kadang disingkat pesediaan. Adapun definisi persediaan barang dagangan menurut Mulyadi (2010:553) adalah barang yang dibeli untuk tujuan dijual kembali dapat disimpulkan bahwa barang dagangan merupakan barang-barang yang disediakan dengan tujuan untuk dijual kembali kepada para konsumen dan digunakan untuk mencatat harga pokok barang dagang selama periode normal kegiatan perusahaan. Dalam sistem akuntasi pembelian manajemen memerlukan informasi mengenai data – data yang diperlukan untuk mengambil keputusan yang tepat dalam menjalankan kegiatan pembelian. Beberapa informasi yang diperlukan oleh manajemen dari sistem akuntansi pembelian adalah sebagai berikut: 1. Jenis persedian yang telah mencapai titik pemesanan kembali (reorder point). 58 Yaitu untuk mengetahui jumlah jenis persediaan barang dagangan yang harus dipesan kembali, agar saat jenis persediaan dibutuhkan, barang dagangan tersebut tersedia dalam gudang. 2. Pesanan pembelian yang telah dikirim kepada pemasok Yaitu untuk mengetahui jumlah pesanan pembelian dan pemasok mana yang dipilih dalam pesanan pembelian 3. Pesanan pembelian yang telah dipenuhi oleh pemasok Yaitu untuk mengetahui jumlah ketersediaan pemasok dalam memenuhi pesanan pembelian 4. Total saldo utang dagang pada tanggal tertentu Yaitu untuk mengetahui total saldo utang dagang perusahaan dan mengetahui tanggal jatuh tempo pembayaran utang dagang yang harus dibayar perusahaan. 5. Saldo utang dagang pada pemasok tertentu Yaitu untuk mengetahui rincian saldo utang dagang dari masing-masing pemasok dan mengetahui tanggal jatuh tempo pembayaran kepada pemasok tersebut. 6. Tambahan kuantitas dan harga pokok persediaan dari pembelian.