BAB 2 LANDASAN TEORI 2.1. Pendekatan Basis Data 2.1.1. Pengertian Basis Data Menurut pendapat Connolly (2010) pengertian database adalah koleksi yang dapat digunakan secara bersama dari data yang berhubungan secara logikal dan deskripsi dari data yang didesain untuk memenuhi informasi yang dibutuhkan dalam organisasi. Database adalah tempat penyimpanan data yang tunggal dan besar yang dapat digunakan secara simultan oleh banyak pengguna dan departemen. Database menurut Kroenke (2002) merupakan koleksi self-describing yang berhubungan dengan data. Sebuah database self-describing yang berarti database tersebut mengandung, sebagai tambahan data sumber dari user, mendeskripsikan strukturnya sendiri. Menurut Harlinda (2007) basis data adalah suatu kumpulan data yang terhubung dan disimpan secara bersama-sama pada suatu media, tanpa adanya suatu kerangkapan data, sehingga mudah untuk digunakan kembali, dapat digunakan oleh satu atau lebih program aplikasi secara optimal, data disimpan tanpa mengalami ketergantungan pada program yang akan menggunakannya, data disimpan sedemikian rupa sehingga apabila ada
8
9 penambahan, pengambilan dan modifikasi data dapat dilakukan dengan mudah dan terkontrol. 2.1.2
Sistem Manajemen Basis Data Menurut pendapat Connolly (2010) Database Management System (DBMS) adalah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara dan mengontrol akses ke database. DBMS adalah perangkat lunak yang berinteraksi dengan user, program aplikasi dan database. Biasanya DBMS menyediakan fasilitas berikut: a. DBMS mengijinkan user untuk mendefinisikan database, biasanya melalui Data Definition Language (DDL). b. DBMS
mengijinkan
user
untuk
memasukkan,
memperbaharui,
menghapus dan mengambil data dari database, biasanya melalui Data Manipulation Language (DML). c. DBMS menyediakan akses kontrol ke database. Pendapat McLeod dan Schell (2004) tentang DBMS yaitu sebuah aplikasi perangkat lunak yang menyimpan struktur dari database dan data itu sendiri, hubungan antara data dalam database dan form, laporan menyinggung database.
10 Keuntungan DBMS: a. Mengurangi redudansi data Jumlah data mengalami pengurangan, dibandingkan dengan ketika file komputer disimpan secara terpisah untuk setiap aplikasi komputer. b. Mencapai independensi data Spesifikasi dari data diselenggarakan di dalam database itu sendiri daripada disetiap program aplikasi. Perubahan mungkin dilakukan sekali untuk struktur data, tanpa memerlukan perubahan pada banyak program aplikasi yang mengakses data. c. Mengambil data dan informasi dengan cepat Hubungan logis dan bahasa query terstruktur memungkinkan pengguna untuk mengambil data dalam hitungan detik atau menit yang mungkin memakan waktu beberapa jam atau hari untuk mengambil menggunakan bahasa pemrograman tradisional. d. Meningkatkan keamanan Kedua mainframe dan mikrokomputer DBMS dapat mencakup tindakan pencegahan multiple levels keamanan seperti password, direktori pengguna dan enkripsi.
11 Kekurangan DBMS: a. Perangkat lunak yang mahal Mainframe DBMS mahal. Komputer mikro berbasis DBMS, biayanya hanya beberapa ratus dolar tetapi dapat mewakili pengeluaran substansial untuk organisasi kecil. b. Mendapatkan konfigurasi perangkat keras yang besar Kemudahan DBMS dapat mengambil informasi lebih banyak pengguna untuk menggunakan database. Jumlah peningkatan user didorong oleh kemudahan penggunaan dapat menyebabkan peningkatan jumlah sumber daya komputer untuk mengakses database. c. Mempekerjakan dan mempertahankan staf DBA DBMS memerlukan pengetahuan khusus untuk memanfaatkan sepenuhnya kemampuan. Ini pengetahuan khusus yang lebih baik disediakan oleh DBA dan stafnya. 2.1.3
Database Language Menurut Connolly (2010) Bahasa utama yang muncul dari perkembangan relational model adalah structure query language, yang biasa disebut SQL. Beberapa tahun terakhir ini, SQL menjadi bahasa standar relational database. Tujuan SQL yaitu sebuah database harus mengijikan user untuk: a. Membuat database dan struktur relasi.
12 b. Melakukan
tugas
manajemen
basis
data,
seperti
memasukan,
memodifikasi dan menghapus data dari relasi yang ada. c. Melakukan query yang sederhana dan rumit. 2.1.3.1 Data Definition Language Menurut Connolly (2010) data definition language adalah sebuah bahasa yang mengijinkan DBA atau user untuk mendeskripsikan dan menamakan entitas-entitas atribut dan relationship yang dibutuhkan untuk aplikasi, bersama dengan associated integrity and security constrains. 2.1.3.2 Data Manipulation Language Menurut Connolly (2010) Data Manipulation Language adalah sebuah bahasa yang menyediakan kumpulan operasi untuk mendukung operasi manipulasi basis data pada data yang tersimpan dalam database. Operasi manipulasi data biasanya mengandung: a. Memasukan data baru kedalam database, b. Memodifikasi data yang disimpan dalam database, c. Mengambil kembali data yang ada dalam database, d. Menghapus data dari database. 2.1.3.3 Fourth Generation Language Menurut Connolly (2010) 4GL adalah non-procedural. User mendefinisikan apa yang akan dibuat, bukan bagaimana. 4GL
13 diharapkan untuk bergantung pada komponen level tinggi yang sering diketahui sebagai Fourth generation tools. User tidak mendefinisikan langkah-langkah program untuk melakukan sebuah tugas, tapi mendefinisikan parameter yang digunakan dalam tools untuk menghasilkan sebuah program aplikasi. 4GLs meliputi: a.
Bahasa persentasi seperti bahasa query dan report generators.
b.
Bahasa speciality, seperti spreadsheet seperti database.
c.
Aplikasi generator yang dapat mendefinisikan, memasukan, memperbaharui, dan menggambil data dari database untuk membangun aplikasi.
d.
Bahasa level tinggi yang digunakan untuk menghasilkan kode aplikasi.
2.1.4
Fungsi – Fungsi DBMS Beberapa fungsi-fungsi dari DBMS yaitu:
1. Data Storage, Retrieval and Update Sebuah DBMS harus melengkapi user dengan kemampuan untuk meyimpan, mengambil dan memperbaharui data di database. 2. A User-Accessible Catalog Sebuah DBMS harus melengkapi sebuah katalog dimana deskripsi dari data item tersimpan dan dapat diakses oleh user.
14 3. Transaction Support Sebuah DBMS harus melengkapi mekanisme yang memastikan semua update yang cocok untuk transaksi yang diberikan yang telah dibuat maupun yang belum dibuat. 4. Concurrency Control Services Sebuah DBMS harus melengkapi mekanisme yang memastikan bahwa database ter-update secara benar ketika beberapa user sedang meng-update database secara bersamaan. 5. Recovery Services Sebuah DBMS harus melengkapi mekanisme untuk memperbaiki database dalam sebuah event bahkan ketika database rusak dengan cara apapun. 6. Authorization Services Sebuah DBMS harus melengkapi mekanisme untuk memastikan hanya user yang memiliki ijin yang dapat mengakses database. 7. Support for Data Communication Sebuah DBMS harus mampu terintegrasi dengan software komunikasi. 8. Integrity Services Sebuah DBMS harus melengkapi arti untuk memastikan kedua data di dalam database dan perubahan yang ada dalam data mengikuti ketentuan yang ada.
15 9. Services to promote data independence Sebuah DBMS harus mengandung fasilitas untuk mendukung kebebasan program dari struktur database yang nyata. 10. Utility services Sebuah DBMS menyediakan sekumpulan keperluan jasa. Program utility membantu DBA mengatur database secara efektif. 2.1.5
Siklus Hidup Aplikasi Basis Data Mengenai siklus hidup alikasi basis data Connolly (2010) mendefinisikan siklus hidup aplikasi basis data sebagai sebuah sistem database adalah sebuah komponon pokok dari organisasi besar dengan sistem informasi yang luas, siklus hidup perkembangan basis data terhubung secara erat dengan siklus hidup dari sistem informasi. Menurut Connoly (2010) siklus hidup aplikasi basis data adalah seperti yang ada pada gambar di bawah ini:
16
Gambar 2.1. Database lifecycle (Connolly 2010) 2.1.5.1 Database Planning Menurut Connolly (2010) database planning adalah aktifitas manajemen
yang
mengijinkan
tahap-tahap
dari
siklus
hidup
perkembangan sistem basis data untuk direalisasikan seefisien dan seefektif mungkin. Langkah pertama yang penting dalam database planning adalah untuk mendefinisikan secara jelas mission statement untuk sistem database. Mission statement mendefinisikan tujuan utama dari sistem
17 database. Sebuah mission statement membantu untuk memperjelas tujuan dari sistem database dan menyediakan jalur yang lebih jelas menuju pembuatan sistem database yang dibutuhkan secara efisien dan efektif. Kegiatan berikutnya melibatkan mission objective. Setiap mission objective harus mengidentifikasikan tugas yang harus didukung oleh sistem database. 2.1.5.2 System Definition Menurut Connolly (2010) system definition mendeskripsikan ruang lingkup dan batasan-batasan dari sistem database dan user view utama. Sebelum mencoba untuk mendesain sistem database, sangat diperlukan untuk pertama-tama mengidentifikasi batasan dari sistem yang kita teliti dan bagaimana interface dengan bagian lain di dalam sistem informasi organisasi. Mengenai user view Connolly (2010) mendefinisikan apa yang dibutuhkan oleh sistem database dari sudut pandang peran kerja tertentu atau area aplikasi perusahaan. Sebuah sistem database dapat memiliki lebih dari satu user view. Mengidentifikasi user view adalah aspek penting dalam membangun sistem database karena user view membantu untuk meyakinkan bahwa tidak ada user utama yang terlupakan ketika membangun kebutuhan untuk sistem database yang baru.
18 2.1.5.3 Requirement Collection and Analysis Menurut pendapat Connolly (2010) requirement collection and analysis adalah proses mengumpulkan dan menganalisis informasi mengenai bagian dari organisasi yang harus didukung oleh sistem database dan menggunakan informasi ini untuk mengidentifikasi kebutuhan untuk sistem yang baru. Informasi yang dikumpulkan untuk setiap user view mencakup: a. Deskripsi dari data yang digunakan atau dihasilkan, b. Detil dari bagaimana data digunakan atau dihasikan, c. Kebutuhan tambahan untuk sistem database yang baru. Informasi
ini
kemudian
dianalisis
untuk
mengidentifikasi
kebutuhan yang akan dimasukkan ke dalam sistem database baru. Ada 3 pendekatan untuk mengatur kebutuhan sistem database dengan user view lebih dari 1 yaitu: a. Centralized approach, b. View integration approach, c. Kombinasi dari keduanya. Centralized approach Menurut Connolly (2010) centralizer approach merupakan kebutuhan untuk setiap user view dijadikan satu kumpulan kebutuhan untuk sistem database yang baru. Data model merepresentasikan semua user view dibuat selama tahapan desain database.
19 View Integration approach Menurut Connolly (2010) view integration approach merupakan kebutuhan untuk setiap user view dibiarkan tetap dalam daftar yang terpisah. Data model yang merepresentasikan setiap user view dibuat, kemudian disatukan selama tahapan mendesain database. Data model yang merepresentasikan satu user view disebut local data model. Local data model yang disatukan dalam tahapan database desain menghasikan global data model, yang merepresentasikan semua kebutuhan user untuk database. 2.1.5.4 Database Design Menurut Connolly (2010) database design adalah proses untuk membuat desain yang dapat mendukung mission statement dan mission objective dari perusahaan untuk memenuhi kebutuhan sistem database. Ada dua pendekatan utama untuk desain dari sebuah database yaitu “bottom up” dan “top down”. Pendekatan bottom up dimulai pada level dasar dari atribut , dimana melalui analisis dari gabungan atribut yang disatukan menjadi relasi yang merepresentasikan tipe dari entitas dan relationship. Pendekatan bottom up sangat cocok untuk mendesain database yang sederhana dan yang memiliki atribut dalam jumlah yang kecil. Akan teteapi pendekatan ini menjadi sulit ketika diterapkan untuk
20 desain database yang lebih rumit dengan jumlah atribut yang lebih besar. Pendekatan yang paling cocok untuk mendesain database yang rumit adalah menggunakan pendekatan top down. Pendekatan ini dimulai dengan mengembangkan data model yang memiliki beberapa entitas dan relationship dengan level tinggi kemudian diterapkan perbaikan top down secara berturut-turut untuk mengidentifikasikan entitas, relationship dengan level yang lebih rendah dan associated attributes. Data Modelling Mengenai data modeling Connolly (2010) berpendapat ada dua tujuan utama dari data modelling yaitu untuk membantu dalam pemahaman arti dari data dan untuk memfasilitasi komunikasi mengenai kebutuhan informasi. Sebuah data model mempermudah untuk memahami arti dari data dan dengan demikian kita membuat model data untuk meyakinkan kita mengerti mengenai: a. Perspektif setiap user mengenai data. b. Sifat alami data itu sendiri, independen dari representasi fisikalnya. c. Kegunaan data dari user view. Menurut Connolly (2010) terdapat 3 fase, database design dibuat dari 3 fase utama yaitu konseptual, logikal dan fisikal desain.
21 2.1.5.5 DBMS Selection DBMS selection menurut Connolly (2010) merupakan pemilihan DBMS yang sesuai untuk mendukung sistem database. Jika tidak ada DBMS , bagian yang sesuai dari lifecycle untuk membuat pemilihan adalah antara fase database design konseptual dan logikal. Selecting the DBMS a. Mendefinisikan syarat-syarat sebagai referensi pembelajaran, b. Mendaftarkan 2 atau 3 produk, c. Mengevaluasi produk, d. Merekomendasi pemilihan dan menghasilkan laporan. 2.1.5.6 Application Design Menurut Connolly (2010) application design yaitu deesain dari user interface dan program aplikasi yang menggunakan dan memproses database. Kita harus memastikan semua fungsi yang dinyatakan dalam spesifikasi kebutuhan user tersedia dalam desain aplikasi untuk sistem database. Hal ini melibatkan mendesain aplikasi program yang mengakses database dan mendesain transaksi. Transaction design Menurut Connolly (2010) transaction adalah sebuah tindakan, atau rangkaian tindakan, yang dilakukan oleh single user atau program aplikasi yang mengakses atau merubah isi dari database.
22 Tujuan dari mendesain transaksi adalah untuk mendefinisikan dan mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan dalam database, termasuk: a. Data yang akan digunakan oleh transaksi, b. Karakteristik fungsional dari transakasi, c. Output dari transaksi, d. Kepentingan user, e. Kecepatan yang diharapkan dalam penggunaan. Menurut Connolly (2010) ada 3 macam transaksi utama yaitu retrieval transaction, update transaction dan mixed transaction: 1. Retrieval transaction digunakan untuk mengambil data untuk ditampilkan di layar atau di produksi sebuah laporan. 2. Update transaction digunakan untuk memasukkan record baru, menghapus record lama atau memodifikasi record yang sudah ada dalam database. 3. Mixed transaction melibatkan retrieval dan update transaction. 2.1.5.7 Prototyping Menurut Connolly (2010) prototyping yaitu membangun sebuah working model untuk sistem database. Sebuah prototype adalah sebuah working model yang tidak biasanya mempunyai semua fitur yang dibutuhkan atau menyediakan semua fungsionalitas dari sistem final.
23 Tujuan utama dari membuat sistem database prototype adalah untuk
mengijinkan
user
menggunakan
prototype
untuk
mengidentifikasi fitur dari sistem yang bekerja dengan baik atau tidak mencukupi atau jika mungkin memberikan saran untuk memperbaiki atau fitur baru untuk sistem database. Ada 2 strategi prototyping yang biasanya digunakan yaitu requirements prototyping dan evolutionary prototyping. Requirements prototyping menggunakan prototype untuk menentukan kebutuhan dari sistem database yang diusulkan dan ketika kebutuhan itu terpenuhi maka prototype akan dibuang. Evolutionary prototyping digunakan dengan tujuan yang sama, perbedaan yang penting adalah prototype yang digunakan tidak dibuang akan tetapi dengan pengembangan lebih lanjut akan menjadi sistem database yang bekerja. 2.1.5.8 Implementation Menurut Connolly (2010) implementation adalah realisasi fisikal dari database dan desain aplikasi. Program aplikasi diimplementasikan menggunakan 3GL atau 4GL. Sebagian dari aplikasi ini adalah transaksi database yang diimplementasikan menggunakan DML dari target DBMS, mungkin dilekatkan dengan host programming language seperti Visual Basic, VB.net, Python, delphi, C, C++, C#, Java, COBOL, Fortran, Ada Atau Pascal. Kita juga mengimplementasikan komponen lainnya dalam desain aplikasi seperti menu screens, formulir data entry dan laporan.
24 2.1.5.9 Data Conversion and Loading Menurut pendapat Connolly (2010) data conversion dan loading yaitu transfer data yang sudah ada ke dalam database yang baru dan mengkonversi aplikasi yang sudah untuk dijalankan dalam database yang baru. Tahapan ini dibutuhkan hanya ketika sistem database yang baru menggantikan sistem yang lama. Sekarang ini, adalah hal umum sebuah DBMS memiliki kegunaan untuk mengisi file yang ada ke dalam database yang baru. Kegunaan ini biasanya memerlukan spesifikasi dari file asal dan database tujuan dan kemudian secara otomatis mengkonversi data menjadi format yang dibutuhkan dari file database yang baru. 2.1.5.10
Testing Menurut
Connolly
(2010)
testing
adalah
proses
dalam
menjalankan sistem database dengan maksud menemukan error. Kenyataannya, testing tidak bisa menampilkan ketidakadaan dari kesalahan. Testing hanya bisa menampilkan kesalahan software yang terjadi sekarang. Jika testing yang diadakan sukses, testing akan menemukan error dalam program aplikasi dan struktur database yang memungkinkan.
25 2.1.5.11
Operational Maintenance Pendapat Connolly (2010) tentang arti operational maintenance
yaitu suatu proses memonitor dan memelihara database yang telah diinstall. Sistem sekarang bergerak menuju tahapan pemeliharaan dimana mencakup beberapa aktivitas dibawah ini: a. Memonitor performa dari sistem, b. Memelihara dan merubah sistem database (jika dibutuhkan). 2.1.6
Entity Relationship Modelling Menurut Connolly (2010) ER modelling adalah pendekatan dari atas ke bawah untuk mendesain database yang dimulai dengan mengidentifikasi data yang penting yang disebut dengan entitas dan hubungan antar data yang harus di representasikan di dalam model. ERD juga mengungkapkan entitas mana yang secara konseptual harus berhubungan dengan entitas lain. Bagian terakhir dari pembuatan ERD adalah menentukan berapa banyak data individu dalam entitas yang akan berhubungan dengan data individu lain. Ini adalah kunci dalam konseptualisasi yang berdampak bagaimana tabel database sebenarnya dibuat. ERD seperti namanya, berhubungan dengan data dalam perusahaan dan hubungan antara entitas. Ketika pengguna dan spesialis informasi mulai untuk berkomunikasi tentang data yang diperlukan untuk sistem informasi, mereka berbicara dalam hal koleksi bidang data terkait yang bertentangan
26 dengan bidang data individu. Data konseptual ini disebut entitas. Tabel adalah hasil dari entitas yang dipecah ke unit yang lebih kecil sesuai dengan aturan untuk struktur database. Menurut pendapat McLeod dan Schell (2004) ERD adalah konseptualisasi tingkat yang lebih tinggi dari data dan table. 2.1.6.1 Entity Types Menurut Connolly (2010) entity types adalah grup dari objek dengan sifat yang sama, yang diidentifikasikan oleh perusahaan dengan mempunyai keberadaan yang independen. 2.1.6.2 Relationship Types Menurut Connolly (2010) tipe relationship adalah kumpulan asosiasi antara satu atau lebih tipe entiti yang berpartisipasi. Setiap tipe relationship diberi nama yang mendeskripsikan fungsinya. Entitas yang terlibat dalam tipe relationship yang khusus direferensikan sebagai participants dalam relationship itu. Jumlah participants yang ada dalam satu tipe relationship disebut degree dari hubungan tersebut. Oleh karena itu, degree dalam suatu relationship mengindikasikan jumlah tipe entitas yang terlibat dalam sebuah relationship.
Relationship
dengan
2
degree
disebut
binary.
Relationship dengan 3 degree disebut ternary. Relationship dengan 4 degree disebut quarternary.
27 Menurut Connolly (2010) hubungan rekursif adalah tipe relationship dimana tipe entitas yang sama berpartisipasi lebih dari satu kali dengan peran yang berbeda. 2.1.6.3 Attributes Menurut pendapat Connolly (2010) atribut adalah properti dari sebuah entitas atau tipe hubungan. Atribut domain adalah set dari nilai yang diijinkan untuk satu atau lebih atribut. a. Simple attribute Atribut yang terdiri dari satu komponen dengan keberadaan yang independen. b. Composite attribute Atribut yang terdiri dari banyak komponen, masing-masing dengan keberadaan yang independen. c. Single valued attribute Atribut yang memiliki nilai tunggal untuk setiap kejadian dan tipe entitas. d. Multi valued attribute Atribut yang memiliki nilai banyak untuk setiap kejadian dan tipe entitas.
28 e. Derived Attributes Atribut yang merepresentasikan nilai yang dapat diambil dari nilai atribut yang berhubungan atau set dari atribut, tidak perlu dalam tipe entitas yang sama. Keys Beberapa keys menurut Connolly (2010), diantaranya: a. Candidate Key Set minimal dari atribut yang secara unik mengidentifikasi setiap kejadian dan tipe entitas. b. Primary Key Candidate key yang tepilih untuk secara unik mengidentifikasi setiap kejadian dan tipe entitas. c. Composite key Candidate key yang terdiri dari 2 atau lebih atribut. Structural Constraint Menurut
pendapat
Connolly
(2010)
constraint
harus
menggambarkan batasan dalam hubungan seperti dirasakan dalam “dunia nyata”. Tipe utama dari constraint dalam relationship disebut multiplicity. Multiplicity adalah angka yang mungkin muncul dari sebuah entitas yang mungkin berhubungan dengan sebuah tipe entitas yang tunggal dalam hubungan yang khusus.
29 One-to-One Relationship
Gambar 2.2 One-to-One Relationship (Connolly 2010) Maksimum satu branch untuk setiap staff yang terlibat dalam relationship ini dan maksimum satu member dari staff untuk setiap branch, kita menunjuk tipe relationship ini sebagai one-to-one dan biasanya dapat disingkat sebagai (1:1) One-to-Many Relationship
Gambar 2.3 One-to-Many Relationship (Connolly 2010) Setiap relationship (rn) merepresentasikan asosiasi kejadian antara entitas Staff tunggal dan entitas PropertyForRent tunggal. Kita merepresentasikan setiap entity occurence menggunakan nilai untuk
30 atribut primary key dari entitas Staff dan PropertyForRent, yang dinamakan staffNo dan propertyNo. Many-to-Many Relationship
Gambar 2.4 Many-to-Many Relationship (Connolly 2010) Untuk merepresentasikan bahwa setiap property for rent dapat diiklankan dengan nol atau lebih newspaper, kita menaruh ‘0..*’ di entitas Newspaper. Multiplicity for Complex Relationship
Gambar 2.5 Multiplicity for Complex Relationship (Connolly 2010) Cara alternatif untuk merepresentasikan multiplicity constraints 0..1 yang artinya nol atau satu entity occurence. 1..1 yang artinya hanya satu entity occurence.
31 0..* yang artinya nol atau lebih entity occurence. 1..* yang artinya satu atau lebih entity occurence. 5..10 yang artinya minimal 5 sampai maksimum 10 entity occurence. 0,3,6-8 yang artinya nol atau tiga atu enam atau 8 entity occurence. Cardinality and Participation Constraint
Gambar 2.6 Cardinality and Participation Constraint (Connolly 2010) Cardinality mendeskripsikan nilai maksimum dari relationship occurences yang mungkin untuk setiap entitas yang berpartisipasi dalam tipe relationship yang diberikan. Participation menentukan apakah semua atau hanya beberapa entity occurrence yang berpartisipasi dalam satu relationship.
32 2.1.7
Metodologi Perancangan Basis Data Dalam penyusunan skripsi ini menggunakan metode perancangan basis data diantaranya adalah:
2.1.7.1 Perancangan Konseptual Menurut pendapat Connolly (2010) perancangan konseptual adalah sebuah proses mengkonstruksi sebuah model dari data yang digunakan dalam sebuah perusahaan, independen dari semua pertimbangan fisikal. Fase pertama dari database design adalah conceptual database design dan mencakup pembuatan model data konseptual dari bagian perusahaan yang menurut kita menarik untuk dimodelkan. Model data dibuat menggunakan informasi yang didokumentasikan dalam spesifikasi kebutuhan user. Langkah-langkah membuat model data konseptual: Langkah 1 Mengindentifikasi tipe entitas Langkah pertama dalam membuat model data konseptual adalah untuk mendefinisikan obyek utama yang akan digunakan oleh user. Obyek ini adalah tipe entitas untuk model. Salah satu cara mengidentifikasi
entitas
adalah
dengan
memeriksa spesifikasi
kebutuhan user. Cara lain mengidentifikasi entitas adalah dengan mencari obyek yang mempunyai eksistensi sendiri.
33 Langkah 2 Mengindetifikasi tipe relationship Setelah mengidentifikasi entitas, langkah selanjutnya adalah untuk mengidentifikasi semua relationship yang ada di antara entitas. Ketika kita mengidentifikasi entitas, salah satu metode adalah dengan mencari kata benda dalam spesifikasi kebutuhan user. Kita dapat menggunakan grammar
dari
spesifikasi
kebutuhan
untuk
mengidentifikasi
relationship. Biasanya, relationship diindikasikan dengan kata kerja. Langkah 3 Mengidentifikasi dan mengasosiasi atribut dengan tipe entitas atau relationship Tujuannya untuk mengasosiasikan atribut dengan entitas yang sesuai atau tipe relationship. Langkah berikutnya dalam metodologi adalah untuk mengidentifikasikan tipe fakta tentang entitas dan hubungan yang telah kita pilih untuk direpresentasikan dalam database. Langkah 4 Menentukan atribut domain Untuk menentukan domain dari atribut dalam model data konseptual. Tujuan dari langkah ini adalah untuk menentukan semua domain dari setiap atribut dalam model. Langkah 5 Menentukan atribut candidat, primary dan alternate key Untuk mengidentifikasikan candidate keys untuk setiap tipe entitas dan jika ada lebih dari satu candidate key untuk memilih satu
34 menjadi primary key dan yang lainnya sebagai alternate key. Langkah ini memperhatikan pengidentifikasian candidate key dan kemudian memilh salah satu untuk menjadi primary key. Candidate key adalah set minimal dari atribut dari sebuah entitas yang secara unik mengidentifikasikan setiap kejadian dalam entitas tersebut. Kita dapat mengidentifikasikan lebih dari satu candidate key, yang dalam kasus ini kita harus menentukan primary key dan candidate key yang tersisa disebut alternate key. Langkah 6 Mempertimbangkan kegunaan
enhanced modeling
concepts Untuk mempertimbangkan kegunaan dari konsep enhanced modelling seperti spesialisasi atau generalisasi, agegrasi dan komposisi. Dalam langkah ini, kita mempunyai pilihan untuk melanjutkan pengembangan dari ER model menggunakan konsep advanced modelling. Langkah 7 Mengecek model dari redudansi Untuk mengecek adanya redudancy dalam model. Dalam langkah ini, kita memeriksa model data konseptual dengan tujuan spesifik untuk mengidentifikasi adanya redudancy dan menghapusnya apabila ada 3 aktivitas dalam langkah ini adalah: 1. Memeriksa one-to-one relationship 2. Menghapus redundant relationship
35 3. Mempertimbangkan dimensi waktu Langkah 8 Validasi model data konseptual yang berlawanan dengan transaksi user Untuk meyakinkan bahwa model konseptual mendukung transaksi yang membutuhkan. Tujuan dari langkah ini adalah untuk mengecek model untuk meyakinkan model ini mendukung transaksi. Dalam menggunakan model ini, kita mencoba untuk melakukan operasi secara manual. Langkah 9 Mengulang kembali model data konseptual dengan user Untuk meninjau model data konseptual dengan user untuk meyakinkan bahwa mereka mempertimbangkan model untuk menjadi representasi yang ‘benar’ dari kebutuhan data perusahaan. 2.1.7.2 Perancangan Logikal Menurut pendapat Connolly (2010) perancangan logikal adalah sebuah proses mengkonstruksi sebuah model data yang digunakan dalam sebuah perusahaan yang berdasarkan model data spesifik tetapi independen dari semua DBMS dan pertimbangan fisikal lainnya. Fase kedua dari database design adalah logical database design yang menghasilkan pembuatan model data logikal dari bagian perusahaan yang ingin kita modelkan. Model data konseptual dibuat dalam fase sebelumnya disaring dan dipetakan menjadi model data logikal. Melalui proses membuat model data logikal, model itu diuji
36 dan divalidasikan menurut kebutuhan user. Normalisasi digunakan untuk menguji kebenaran dari model data logikal. Normalisasi meyakinkan bahwa relation yang dihasilkan dari model data tidak menampilkan redudansi data. Langkah-langkah membuat model data logikal: Langkah 1 Memperoleh relasi untuk model data logikal Untuk membuat hubungan untuk model data logikal untuk merepresentasikan entitas, relationship dan atribut yang bisa diidentifikasi. Dalam tahap ini kita mendapat hubungan untuk model data logikal untuk merepresentasikan entitas, relationship dan atribut. Langkah 2 Memvalidasi relasi dengan menggunakan normalisasi Untuk memvalidasikan hubungan dalam model data logikal menggunakan normalisasi. Dalam tahap ini kita memvalidasikan pengelompokan dari atribut dalam setiap hubungan menggunakan aturan normalisasi. Tujuan dari normalisasi adalah untuk meyakinkan bahwa set dari hubungan mempunyai minimal dan angka yang cukup dari atribut yang dibutuhkan untuk mendukung kebutuhan data perusahaan. Langkah 3 Memvalidasi relasi yang berlawanan dengan transaksi user Untuk meyakinkan bahwa hubungan dalam model data logikal mendukung transaksi. Tujuan dari langkah ini adalah untuk
37 memvalidasi model data logikal untuk meyakinkan bahwa model ini mendukung transaksi, seperti yang dirincikan dalam spesifikasi kebutuhan user. Dalam langkah ini, kita mengecek bahwa hubungan yang dibuat dalam langkah sebelumnya juga mendukung transaksi ini dan dengan cara demikian meyakinkan bahwa tidak ada error yang terjadi saat membuat hubungan. Langkah 4 Mengecek integrity constrains Mengecek integrity constraint akan direpresentasikan dalam model data logikal. Integrity Constraint adalah constraint yang ditentukan untuk melindungi database dari tidak lengkapnya data, tidak akurat dan tidak konsisten. Langkah 5 Mengulang kembali model data logikal dengan user Untuk meninjau model data logikal dengan user untuk meyakinkan bahwa mereka mempertimbangkan model data menjadi representasi nyata dari kebutuhan data perusahaan. Model data logikal harus sudah lengkap dan didokumentasikan. Langkah 6 Menggabungkan model data logikal kedalam model global Untuk menentukan apakah akan ada perubahan secara signifikan dimasa depan dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan tersebut.
38 Langkah 7 Mengecek pertumbuhan kedepannya Untuk menggabungkan model data logikal secara lokal menjadi model data logical secara global yang merepresentasikan semua user view dari database. Langkah ini hanya dilakukan untuk mendesain database dengan user view lebih dari satu yang diatur menggunakan pendekatan view integration. 2.1.7.3 Perancangan Fisikal Menurut pendapat Connolly (2010) perancangan fisikal adalah suatu proses menghasilkan deskripsi dari implementasi database pada secondary storage. Physical database design mendeskripsikan relasi dasar, organisasi file dan index yang digunakan untuk akses secara efisien untuk mencapai data, associated integrity constraint dan security measure. Physical database design adalah fase ketiga dan terakhir dari proses database design, dimana desainer memutuskan bagaimana database akan diimplementasikan. Secara umum, tujuan utama dari physical database design adalah untuk mendeskripsikan bagaimana kita berencana untuk mengimplementasikan logical database design. Langkah-langkah membuat model data fisikal:
39 Langkah 1 Mengubah model data logikal menjadi target DBMS Untuk menghasilkan skema database relational dari model data logikal yang dapat direpresentasikan dalam DBMS. Aktivitas pertama dari mendesain database fisikal mencakup menerjemahkan hubungan dalam model data logikal menjadi sebuah form yang dapat diimplementasikan dalam DBMS. a. Merancang relasi dasar Menentukan
bagaimana
merepresentasikan
hubungan dasar dalam model data logikal dalam DBMS. Untuk memulai proses mendesain fisikal, pertama kita menyusun dan memahami informasi mengenai hubungan yang dihasilkan selama mendesain database logikal. b. Merancang representasi yang diperoleh data Untuk menentukan bagaimana merepresentasikan semua derived data yang ada dalam model data logikal di DBMS. Atribut yang nilainya dapat ditemukan dengan menguji nilai dari atribut lain dikenal sebagai atribut derived atau atribut calculated. c. Merancang general constrains Untuk mendesain general constraint untuk DBMS. Pembaharuan dari hubungan dapat didesak oleh
40 integrity constraint yang mengatur ‘dunia nyata’ dari transaksi yang direpresentasikan dengan pembaharuan. Langkah 2 Merancang file organisasi dan indeks Untuk menentukan organisasi file yang optimal untuk menyimpan hubungan dasar dan indeks yang dibutuhkan untuk mencapai performa yang dapat diterima, yang artinya relasi dan tuple akan disimpan dalam penyimpanan secondary. a. Menganalisa transaksi Untuk memahami fungsionalitas dari transaksi yang akan berjalan di dalam database dan untuk menganalisa transaksi-transaksi yang penting. Untuk membuat desain database fisikal secara efektif, sangat dibutuhkan untuk mempunyai pengetahuan mengenai transaksi atau query-query yang akan berjalan di dalam database. b. Memilih organisasi file Untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Satu dari tujuan utama mendesain database fisikal adalah untuk menyimpan dan mengakses data dengan cara yang efisien.
41 c. Memilih indeks Untuk menentukan apakah penggunaan indeks dapat memperbaiki performa sistem. Salah satu pendekatan untuk memilih organisasi file yang cocok untuk relasi adalah untuk menjaga tuple tidak tersusun dan membuat indeks secondary sebanyak yang dibutuhkan. d. Memperkirakan kebutuhan disk space Untuk menentukan jumlah disk space yang dibutuhkan oleh database. Tujuan dari langkah ini adalah untuk menentukan jumlah disk space untuk mendukung
implementasi
database
dalam
penyimpanan secondary. Langkah 3 Merancang user view Untuk mendesain user view yang diidentifikasikan selama pengumpulan kebutuhan dan analisis dari siklus hidup pengembangan sistem basis data. Langkah 4 Merancang mekanisme keamanan Untuk mendesain mekanisme kemanan untuk database yang dispesifikasikan oleh user selama pengumpulan kebutuhan dari siklus hidup pengembangan sistem basis data. Tujuan dari langkah ini adalah untuk menentukan bagaimana kebutuhan keamanan ini akan
42 direalisasikan. Beberapa sistem menawarkan fasilitas keamanan yang berbeda dengan yang lain. Langkah 5 Mempertimbangkan introduksi dari redundansi kontrol Untuk menentukan apakah memperkenalkan redundancy dalam controlled manner dengan aturan normalisasi akan memperbaiki performa sistem. Langkah 6 Mengawasi dan memperbaiki sistem operasi Untuk mengawasi sistem operasi dan memperbaiki performa dari sistem, untuk mengkoreksi desain yang tidak sesuai atau kebutuhan yang berubah secara refleks. Untuk aktifitas ini kita harus mengingat bahwa salah satu dari tujuan mendesain database fisikal adalah untuk menyimpan dan mengakses data dengan cara yang efisien. 2.1.8
Normalisasi Menurut pendapat Connolly (2010) mengenai normalisasi yaitu sebuah teknik untuk memproduksi sebuah kumpulan hubungan dengan properti yang diinginkan, untuk memberikan kebutuhan data dari perusahaan.
2.1.8.1 Tujuan Normalisasi Tujuan normalisasi adalah untuk mengidentifikasi sebuah kumpulan hubungan yang cocok yang mendukung kebutuhan data dari perusahaan.
43 2.1.8.2 Proses Normalisasi Proses Normalisasi menurut Connolly (2010) diantaranya sebagai berikut: Unnormalized form (UNF) Sebuah tabel yang mengandung satu atau lebih grup yang berulang. First Normal form (1NF) Sebuah hubungan dimana persimpangan dari setiap baris dan kolom mengandung satu dan hanya satu nilai Second Normal form (2NF) Suatu hubungan yang didalam 1NF-nya dan setiap atribut nonprimary key-nya secara keseluruhan fungsinya bergantung pada primary key. Normalisasi dari 1NF ke 2NF melibatkan penghapusan partial dependencies. Third Normal Form (3NF) Sebuah hubungan dimana 1NF dan 2NF dimana atribut yang bukan primary key secara transitive bergantung pada primary key. Normalisasi dari 2NF ke 3NF melibatkan penghapusan transitive dependencies.
44 2.2 Tools Yang Digunakan Tools yang digunakan dalam penulisan skripsi ini adalah Diagraming Tools dan Pemahaman Obyek Teori. 2.2.1
Diagraming Tools Diagraming Tools yang digunakan adalah sebagai berikut:
2.2.1.1 State Transition Diagram Menurut Whitten, Bentley dan Dittman (2004) State Transition Diagram
(STD)
adalah
suatu
alat
yang
digunakan
untuk
menggambarkan urutan dan variasi screen yang dapat terjadi selama satu sesi pengguna. Notasi-notasi yang digunakan dalam STD, yaitu: a. Kotak digunakan untuk menggambarkan state sistem. b. Anak panah menunjukkan arah perubahan state. c. Kondisi dinyatakan dengan tulisan yang diberi garis bawah. d. Aksi dinyatakan dengan tulisan tanpa garis bawah. Biasanya terletak dibawah kondisi State 1 Kondisi Aksi State 2
Gambar 2.7 Notasi State Transition Diagram (STD)
45 2.2.1.2 Data Flow Diagram Menurut McLeod dan Schell (2004) Data Flow Diagram adalah representasi grafis suatu sistem yang menggunakan empat bentuk simbol untuk menggambarkan bagaimana data mengalir melalui proses yang saling berhubungan. Simbol merupakan unsur-unsur lingkungan yaitu sistem interface, proses,
aliran
data
dan
penyimpanan
data.
Diagram
yang
mendokumentasikan sistem dengan lebih ringkas disebut dengan diagram konteks dan diagram yang menyediakan lebih detail disebut diagram gambar n. Menurut pendapat McLeod dan Schell, 2004) terdapat elemenelemen DFD, diantaranya: a. Environmental elements Unsur lingkungan yang ada di luar batas sistem. Unsurunsur ini menyediakan sistem dengan input data dan menerima output sistem data. Dalam DFD tidak ada perbedaan dibuat antara data dan informasi. Semua aliran dianggap sebagai data. Nama entitas sering digunakan untuk menggambarkan unsur-unsur lingkungan karena mereka menandai titik dimana sistem berakhir. Sebuah entitas direpresentasikan dalam DFD dengan persegi atau persegi panjang dan diberi label dengan nama unsur lingkungan.
46 b. Processes Proses merupakan sesuatu yang mengubah input menjadi output. Hal ini dapat diilustrasikan dengan lingkaran, persegi panjang horisontal atau persegi panjang tegak dengan sudut dibulatkan. Setiap simbol proses diidentifikasikan dengan label. c. Data Flows Sebuah aliran data terdiri dari sekelompok elemen data logis terkait dengan perjalanan dari satu point atau proses menuju ke proses yang lain. Panah simbolis digunakan untuk menggambarkan aliran dan dapat ditarik dengan garis lurus atau garis melengkung. d. Data Storage Data storage adalah gudang data.
Gambar 2.8 Notasi Data Flow Diagram (DFD)
47 2.2.2
Software Tools Mengenai pemrograman
software
tools
memungkinkan
O’Brien
(2008)
pemrogram
untuk
membahas
bahasa
mengembangkan
serangkaian perintah yang membentuk program komputer. Banyak bahasa pemrograman yang berbeda telah dikembangkan dengan masing-masing memiliki kosakata, tata bahasa dan penggunaan yang berbeda-beda. 2.2.2.1 MySQL Menurut Kroenke (2006) MySQL adalah sebuah open source produk DBMS yang dapat dijalankan pada UNIX, Linux dan Windows. Ironisnya, karena keterbatasan transaksi manajemen dan kapasitas login, MySQL sangat cepat untuk aplikasi dengan query asli. Beberapa perusahaan web-oriented data publishing memelihara database mereka dengan oracle tetapi mereka mengunduh MySQL untuk query publishing pada web server mereka. 2.2.2.2 HTML Menurut pendapat Kroenke (2006) Hypertext Markup Language (HTML) adalah bahasa pendeskripsi halaman yang menciptakan dokumen-dokumen hypertexts atau hypermedia. HTML memasukkan kode-kode pengendali dalam sebuah dokumen pada berbagai poin yang dapat Anda spesifikasikan, yang dapat menciptakan hubungan (hyperlink) dengan bagian lain dari dokumen tersebut atau dengan dokumen lain yang berada di World Wide Web
48 (WWW). HTML memasang kode-kode pengendali dalam teks ASCII dari dokumen yang menentukan judul, subjudul, grafik, komponen multimedia dan juga hyperlink dalam dokumen tersebut. 2.2.2.3 PHP Mengacu pada pendapat Ullman (2005) mengenai PHP biasanya dikenal sebagai “Personal Home Page” yang dibuat pada tahun 1994 oleh Rasmus Lerdorf untuk melacak pengunjung yang datang untuk resume online miliknya. PHP melekat pada HTML yang artinya PHP dapat diselipkan didalam HTML dimana dapat membuat membangun website dinamis menjadi lebih mudah. PHP adalah scripting language berlawanan dengan programming language. PHP dirancang untuk menulis Web Scripts bukan sebagai aplikasi yang berdiri sendiri. 2.3 Pemahaman Obyek Studi Penjelasan yang mengenai obyek studi yang berhubungan dengan topik skripsi. 2.3.1
Pengertian Penjualan Menurut Kotler (2006) pengertian penjualan adalah proses dimana kebutuhan pembeli dan penjualan dipenuhi, melalui antar pertukaran informasi dan kepentingan. Menurut Mulyadi (2001) dilihat dari segi pembayarannya, maka penjualan dapat dikelompokkan menjadi 2, yaitu:
49 a. Penjualan Kredit Penjualan kredit dilakukan oleh perusahaan jika order dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Kegiatan penjualan secara kredit ini ditangai oleh perusahaan melalui sistem penjualan kredit. b. Penjualan Tunai Dalam transaksi penjualan tunai, barang atau jasa baru diserahkan oleh perusahaan kepada pelanggan apabila perusahaan telah menerima pembayaran tunai dari pelanggan. 2.3.1.1 Fungsi yang terkait dalam penjualan Menurut Mulyadi (2001) fungsi yang terkait dalam sistem penjualan kredit, antara lain: a. Fungsi kredit Dalam transaksi penjualan kredit dengan kartu kredit, fungsi ini bertanggung jawab atas pemberian kartu kredit kepada pelanggan terpilih. b. Fungsi penjualan Fungsi penjualan bertanggung jawab melayani kebutuhan barang pelanggan. Fungsi penjualan mengisi faktur penjualan kartu kredit untuk memungkinkan fungsi gudang dan fungsi pengiriman pelanggan.
melaksanakan
penyerahan
barang
kepada
50 c. Fungsi gudang Fungsi gudang menyediakan barang yang diperlukan oleh pelanggan sesuai dengan yang tercantum dalam tembusan faktur penjualan kartu kredit yang diterima dari fungsi penjualan. d. Fungsi pengiriman Fungsi pengiriman bertanggung jawab untuk menyerahkan barang yang kuantitas, mutu, dan spesifikasinya sesuai dengan yang tercantum dalam tembusan faktur penjualan kartu kredit yang diterima dari fungsi penjualan.
Fungsi ini juga
bertanggung jawab untuk memperoleh tanda tangan dari pelanggan di atas faktur penjualan kartu kredit sebagai bukti telah diterimanya barang yag dibeli oleh pelanggan. e. Fungsi akuntansi Fungsi akuntansi bertanggung jawab untuk mencatat transaksi bertambahnya piutang kepada pelanggan ke dalam kartu piutang berdasarkan faktur penjualan kartu kredit yang diterima dari fungsi pengiriman. Di samping itu, fungsi akuntansi bertanggung jawab atas pencatatan transaksi penjualan di dalam jurnal penjualan. f. Fungsi penagihan Fungsi penagihan bertanggung jawab untuk membuat surat tagihan secara periodik kepada pemegang kartu kredit.
51 2.3.1.2 Jaringan Prosedur yang Membentuk Sistem Penjualan Jaringan prosedur yang membenuk sistem penjualan dengan kartu kredit adalah: a. Prosedur order penjualan Dalam prosedur ini, fungsi penjualan menerima order dari pembeli dan menambahkan informasi penting pada surat order dari pembeli. Fungsi penjualan kemudian membuat faktur penjualan kartu kredit dan mengirimkannya kepada berbagai fungsi yang lain untuk memungkinkan fungsi tersebut memberikan kontribusi dalam melayani order dari pembeli. b. Prosedur pengiriman barang Dalam prosedur ini, fungsi gudang menyiapkan barang yang diperlukan oleh pembeli dan fungsi pengiriman mengirimkan barang kepada pembeli sesuai dengan informasi yang
tercantum dalam faktur penjualan kartu kredit yang
diterima dari fungsi gudang. Pada saat penyerahan barang, fungsi pengiriman meminta tanda tangan penerimaan barang dari pemegang kartu kredit atas faktur penjualan kartu kredit. c. Prosedur pencatatan piutang Dalam prosedur ini, fungsi akuntansi mencacat tembusan faktur penjualan kartu kredit ke dalam kartu piutang.
52 d. Prosedur penagihan Dalam prosedur ini, fungsi penagihan menerima faktur penjualan kartu kredit dan mengarsipkannya menurut abjad. Secara periodik fungsi penagihan membuat surat tagihan dan mengirimkannya kepada pemegang kartu kredit perusahaan dilampiri dengan faktur penjualan kartu kredit. e. Prosedur pencatatan penjualan Dalam prosedur ini, fungsi akuntansi mencatat transaksi penjualan kartu kredit ke dalam jurnal penjualan. 2.3.1.3 Dokumen pada Sistem Penjualan Dokumen yang digunakan untuk melaksanakan sistem penjualan kredit, antara lain: a. Faktur penjualan kartu kredit Dokumen ini digunakan untuk merekam transaksi penjualan kredit dengan kartu kredit. Lembar ke-1 dan ke-2 berfungsi sebagai dasar pembuatan surat tagihan yang secara periodik dibuat oleh fungsi penagihan dan dikirimkan ke pelanggan. Oleh karena itu, fungsi pengiriman harus mendapatkan tanda tangan di atas faktur penjualan kartu kredit lembar ke-1 dan ke-2 pada saat fungsi tersebut menyerahkan barang kepada pelanggan.
Lembar ke-3
berfungsi sebagai perintah kepada gudang untuk menyiapkan barang yang dibutuhkan oleh pelanggan, dan lembar ke-4 berfungsi sebagai perintah pengiriman barang kepada fungsi
53 pengiriman. Lembar ke-2 dokumen ini tetap disimpan di dalam arsip fungsi akuntansi, dan lembar ke-1 dilampirkan pada surat tagihan yang dikirimkan secara periodik kepada pelanggan. b. Surat tagihan Surat tagihan ini merupakan turnaround document yang isinya dibagi menjadi dua bagian : bagian atas merupakan dokumen yang harus disobek dan dikembalikan bersama cek oleh pelanggan ke perusahaan, sedangkan bagian bawah berisi rincian transaksi pembelian yang dilakukan pelanggan dalam periode tertentu. 2.3.2
Pembelian Menurut Mulyadi (2001) sistem akuntansi pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Transaksi pembelian dapat digolongkan menjadi dua yaitu pembelian lokal dan impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri, sedangkan pembelian impor adalah pembelian dari pemasok luar negeri.
2.3.2.1 Fungsi yang Terkait dalam Pembelian Berikut ini fungsi – fungsi yang terkait dalam pembelian, yaitu: a. Fungsi gudang Dalam sistem akuntansi pembelian, fungsi gudang bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk
54 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. b. Fungsi pembelian Fungsi pembelian bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok yang telah dipilih. Fungsi pembelian membuat perjanjian syarat pembelian dengan pemasok. c. Fungsi penerimaan Fungsi penerimaan bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima dari pemasok berdasarkan pesanan pembelian dan faktur pembelian dari pemasok guna menentukan mengnai dapat atau tidaknya barang tersebut diterima oleh perusahaan. Fungsi penerimaan ini juga bertanggung jawab untuk menerima barang dari pemasok yang berasal dari transaksi retur penjualan. d. Fungsi akuntansi Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat utang dan fungsi pencatat persediaan. Fungsi pencatat utang bertanggung jawab untuk mencatat transaksi pembelian ke dalam register bukti kas keluar dan untuk menyelenggarakan arsip dokumen sumber (bukti kas keluar) yang
55 berfungsi sebagai catatan utang atau menyelenggarakan kartu utang sebagai buku pembantu utang. Fungsi pencatat persediaan bertanggung jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan. 2.3.2.2 Jaringan prosedur yang membentuk Sistem Pembelian Dalam melakukan sistem akuntansi pembelian perlu dilakukan prosedur yang merupakan tahap-tahap proses terjadinya transaksi pembelian. Beberapa prosedur yang membentuk sistem akuntansi pembelian, antara lain: a. Prosedur permintaan pembelian Dalam permintaan
prosedur pembelian
ini,
fungsi
dalam
gudang
dalam
mengajukan
dokumen
surat
permintaan pembelian kepada fungsi pembelian. Jika barang tidak disimpan di gudang (barang langsung pakai) , fungsi yang memakai barang mengajukan permintaan pembelian langsung ke fungsi pembelian dengan mengajukan surat permintaan pembelian. b. 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 barang yang diperlukan oleh perusahaan. Dari
56 pemasok akan mengirim daftar penawaran harga barang yang dikehendaki. c. Prosedur order pembelian Dalam prosedur ini, fungsi pembelian mengirim order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit – unit organisasi yang lain dalam perusahaan (contohnya fungsi penerimaan, fungsi yang meminta barang, dan fungsi pencatat utang) mengenai order pembelian yang sudah dikeluarkan oleh perusahaan. d. 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. Barang yang telah diterima diserahkan ke bagian gudang untuk disimpan. e. Prosedur pencatatan utang Dalam prosedur ini, fungsi penerimaan memberi laporan penerimaan barang ke fungsi akuntansi . Fungsi akuntansi juga menerima faktur dari pemasok untuk dicocokan dengan laporan penerimaan barang. Setelah itu fungsi akuntansi akan memeriksa dokumen – dokumen yang berhubungan dengan
57 pembelian dan menyelenggarakan pencatatan utang atau mengarsipkan dokumen sumber sebagai catatan utang. 2.3.2.3 Dokumen pada sistem pembelian Dokumen merupakan bukti untuk merekam terjadinya transaksi yang dilakukan oleh perusahaan. Adapun dokumen yang digunakan dalam sistem akuntansi pembelian, antara lain: a. Surat permintaaan pembelian Dokumen ini merupakan formulir yang diisi oleh fungsi gudang atau fungsi pemakai barang untuk meminta fungsi pembelian melakukan pembelian barang dagangan dengan jenis , jumlah, dan mutu seperti yang tertera pada surat permintaan pembelian. Surat permintaan pembelian ini biasanya dibuat 2 lembar untuk setiap permintaan, 1 lembar untuk fungsi pembelian, dan tembusannya untuk arsip yang meminta barang. b. Surat permintaan penawaran harga Dokumen ini digunakan untuk meminta penawaran harga bagi barang yang pengadaannya tidak bersifat berulang kali terjadi, yang menyangkut jumlah rupiah pembelian yang besar. c. Surat order pembelian Dokumen ini digunakan untuk memesan barang kepada pemasok yang telah dipilih.
58 d. Laporan penerimaan barang Dokumen ini dibuat oleh fungsi penerimaan untuk menunjukkan bahwa barang yang telah diterima dari pemasok telah memenuhi jenis, spesifikasi, mutu dan kuantitas seperti yang tercantum dalam surat order pembelian. e. Surat perubahan order pembelian Terkadang diperlukan perubahan terhadap isi surat order pembelian yang sebelumnya telah diterbitkan Perubahan tersebut dapat berupa perubahan kuantitas, jadwal penyerahan barang, spesifikasi , penggantian atau hal lain yang bersangkutan dengan perubahan bisnis. Biasanya perubahan tersebut diberitahukan kepada pemasok secara resmi dengan menggunakan surat perubahan order pembelian. f. Bukti kas keluar Dokumen ini dibuat oleh fungsi akuntansi berdasarkan pencatatan transaksi pembelian, berfungsi sebagai perintah pengeluaran kas pembayaran utang kepada pemasok dan sekaligus sebagai surat pemberitahuan kepada kreditur mengenai maksud pembayaran. 2.3.3
Persediaan Menurut Warren, Reeve dan Fess (2008) persediaan (inventory) digunakan untuk mengindikasikan: 1. Barang dagang yang disimpan untuk kemudian dijual dalam operasi bisnis perusahaan.
59 2. Bahan yang dipergunakan dalam proses produksi atau yang disimpan untuk tujuan itu. Menurut Assauri (2004) persediaan adalah sejumlah bahan-bahan, parts-parts yang disediakan dan bahan-bahan dalam proses yang terdapat dalam perusahaan untuk proses produksi, serta barang-barang jadi atau produk yang disediakan untuk memenuhi permintaan dari konsumen atau langganan setiap waktu. Menurut Mulyadi (2001) persediaan terdiri dari persediaan produk jadi, persediaan produk dalam proses, persediaan bahan baku, persediaan bahan penolong, persediaan bahan habis pakai pabrik, persediaan suku cadang. 2.3.3.1 Fungsi yang Terkait dalam Persediaan Berikut ini fungsi – fungsi yang terkait dalam persediaan , yaitu: a. Panitia penghitungan fisik persediaan Panitia ini berfungsi untuk melaksanakan penghitungan fisik persediaan dan menyerahkan hasil penghitungan fisik tersebut kepada bagian kartu persediaan untuk digunakan sebagai dasar adjustment terhadap catatan persediaan dalam kartu persediaan. b. Fungsi akuntansi Dalam penghitungan fisik persediaan, fungsi akuntansi bertugas untuk: 1. Mencantumkan harga pokok satuan persediaan yang dihitung ke dalam daftar hasil penghitungan fisik.
60 2. Mengalikan kuantitas dan harga pokok per-satuan yang tercantum dalam hasil daftar penghitungan fisik 3. Mencantumkan harga pokok total dalam daftar hasil penghitungan fisik 4. Melakukan
adjustment
terhadap
kartu
persediaan
berdasarkan data hasil penghitungan fisik persediaan. 5. Membuat bukti memorila untuk mencatat adjustment data persediaan
dalam
jurnal
umum
berdasarkan
hasil
penghitungan fisik persediaan. c. Fungsi Gudang Dalam sistem penghitungan fisik persediaan , fungsi gudang bertanggung jawab untuk melakukan adjustment data kuantitas persediaan yang dicatat dalam kartu gudang berdasarkan hasil penghitungan fisik persediaan. 2.3.3.2 Jaringan Prosedur yang membentuk Sistem Persediaan Dalam menjalankan sistem persediaan perlu dilakukan prosedur yang merupakan tahap – tahap proses terjadinya transaksi persediaan. Beberapa prosedur yang membentuk sistem persediaan, antara lain: a. Prosedur pencatatan produk jadi. Prosedur ini merupakan salah satu prosedur dalam sistem akuntansi biaya produksi. Dalam prosedur ini, dicatat harga pokok produk jadi yang didebitkan dalam rekening barang dalam proses. Catatan akuntansi yang digunakan dalam
61 prosedur pencatatan produk jadi adalah kartu gudang, kartu persediaan dan jurnal umum. b. Prosedur pencatatan harga produk jadi yang dijual. Prosedur ini merupakan salah satu prosedur dalam sistem penjualan. Catatan akuntansi yang digunakan dalam prosedur pencatatan harga produk jadi yang dijual adalah kartu gudang, kartu persediaan, dan jurnal umum. c. Prosedur pencatatan harga produk jadi yang diterima kembali dari pembeli. Prosedur ini merupakan salah satu prosedur yang membentuk sistem retur penjualan. Jika produk jadi yang telah dijual dikembalikan oleh pembeli, maka transaksi retur penjualan ini akan mempengaruhi persediaan produk jadi, yaitu menambah kuantitas produk jadi dalam kartu gudang yang diselenggarakan oleh bagian gudang dan menambah kuantitas dan harga pokok produk jadi yang dicatat oleh bagian kartu persediaan produk jadi. Catatan akuntansi yang digunakan dalam prosedur pencatatan harga pokok produk jadi yang diterima kembali dari pembeli adalah kartu gudang, kartu persediaan dan jurnal umum atau jurnal retur persediaan jika perusahaan menggunakan jurnal khusus.
62 d. Prosedur pencatatan tambahan dan penyesuaian kembali harga pokok persediaan produk dalam proses. Pencatatan persediaan produk dalam proses biasanya dilakukan oleh perusahaan pada akhir periode, pada saat dibuat laporan keuangan bulanan dan laporan keuangan tahunan. e. Prosedur pencatatan harga pokok persediaan yang dibeli. Prosedur ini merupakan salah satu prosedur yang membentuk sistem pembelian. Dalam prosedur ini, dicatat harga pokok persediaan yang dibeli. f. Prosedur
pencatatan
harga
pokok
persediaan
yang
dikembalikan kepada pemasok. Prosedur ini merupakan salah satu prosedur yang membentuk sistem retur pembelian. Jika persediaan yang telah dibeli dikembalikan kepada pemasok, maka transaksi retur pembelian
ini
akan
mempengaruhi
persediaan
yang
bersangkutan, yaitu mengurangi kuantitas persediaan dalam kartu gudnag yang diselenggarakan oleh bagian gudang serta mengurangi kuantitas dan harga pokok persediaan dalam kartu penyediaan yang bersangkutan. g. Prosedur permintaan dan pengeluaran barang gudang. Prosedur ini merupakan salah satu prosedur yang membentuk sistem akuntansi biaya produksi. Pada prosedur ini dicatat harga pokok persediaan bahan baku, bahan
63 penolong, bahan habis pakai pabrik, dan suku cadang yang digunakan dalam proses kegiatan produksi dan kegiatan non produksi. h. Prosedur pencatatan tambahan harga pokok persediaan karena pengembalian barang gudang. Prosedur ini melakukan transaksi pengembalian barang gudang, mengurangi biaya dan menambah persediaan barang di gudang. Jurnal yang dibuat untuk mencatat transaksi tersebut ada di dalam jurnal umum. i. Sistem penghitungan fisik persediaan. Sistem perhitungan fisik persediaan umumnya digunakan oleh perusahaan untuk menghitung secara fisik persediaan yang disimpan di gudang. Hasilnya digunakan untuk meminta pertanggungjawaban bagian gudang mengenai pelaksanaan fungsi penyimpanan dan pertanggungjawaban bagian kartu persediaan mengenai kendala catatan persediaan yang diselenggarakan, serta untuk melakukan penyesuaian terhadap catatan persediaan di bagian kartu persediaan 2.3.3.3 Dokumen pada sistem persediaan Dokumen merupakan bukti untuk merekam terjadinya transaksi yang dilakukan oleh perusahaan.Adapun dokumen yang digunakan dalam sistem persediaan, antara lain:
64 a. Laporan produk selesai Laporan produk selesai digunakan oleh bagian gudang untuk mencatat tambahan kuantitas produk jadi dalam kartu gudang. b. Bukti memorial Bukti memorial digunakan untuk mencatat tambahan kuantitas dan harga pokok persediaan produk jadi dalam kartu persediaan dan digunakan sebagai dokumen sumber dalam mencatat transaksi selesainya produk jadi dalam jurnal umum. c. Surat order pengiriman Surat order pengiriman diterima oleh bagian gudang dari bagian order penjualan. Setelah bagian gudang mengisi surat order pengiriman tersebut dengan kuantitas produk jadi yang diserahkan kepada bagian pengiriman, atas dasar surat order pengiriman tersebut bagian gudang mencatat kuantitas yang diserahkan ke bagian pengiriman dalam kartu gudang. d. Faktur penjualan Harga pokok produk jadi yang dijual dicatat oleh bagian kartu persediaan dalam kartu persediaan atas dasar tembusan faktur yang diterima oleh bagian tersebut dari bagian penagihan.
65 e. Laporan penerimaan barang Laporan penerimaan barang digunakan oleh bagian gudang untuk mencatat kuantitas persediaan yang dikirimkan kembali kepada pemasok ke dalam kartu gudang. f. Laporan pengiriman barang Laporan pengiriman barang digunakan oleh bagian gudang untuk mencatat kuantitas persediaan yang dikirimkan kembali kepada pemasok ke dalam kartu gudang. g. Bukti kas keluar Bukti
kas
keluar
yang
dilampiri
dengan
laporan
penerimaan barang, surat order pembelian, dan faktur dari pemasok dipakai sebagai dokumen sumber dalam pencatatan harga pokok persediaan yang dibeli dalam register bukti kas keluar atau voucher register. Bukti kas keluar juga dipakai sebagai dasar pencatatan tambahan kuantitas dan harga pokok persediaan ke dalam kartu persediaan. h. Memo kredit Memo kredit yang diterima dari bagian order penjualan digunakan oleh bagian kartu persediaan untuk mencatat kuantitas dan harga pokok produk jadi yang dikembalikan oleh pembeli ke dalam kartu persediaan. i. Memo debit Memo debit yang diterima dari bagian pembelian digunakan oleh bagian kartu persediaan untuk mencatat
66 kuantitas dan harga pokok persediaan yang dikembalikan kepada pemasok ke dalam kartu persediaan. j. Bukti permintaan dan pengeluaran barang gudang Bukti ini dipakai oleh bagian gudang untuk mencatat pengurangan persediaan karena pemakaian intern. Bukti ini digunakan oleh bagian kartu persediaan untuk mencatat berkurangnnya kuantitas dan harga pokok persediaan karena pemakaian intern. Bukti ini juga digunakan sebagai dojumen sumber dalam pencatatan pemakaian persediaan ke dalam jurnal pemakaian bahan baku atau jurnal umum. k. Bukti pengembalian barang gudang Dokumen ini digunakan oleh bagian gudang untuk mencatat tambahan kuantitas persediaan ke dalam kartu gudang.Dokumen ini juga dipakai oleh bagian kartu persediaan untuk mencatat tambahan kuantitas dan harga pokok persediaan ke dalam kartu persediaan, untuk mencatat berkurangngnya biaya ke dalam kartu biaya dan untuk mencatat pengembalian barang gudang tersebut ke dalam jurnal umum. l. Kartu perhitungan fisik (inventory tag) Dokumen
ini
digunakan
untuk
merekam
hasil
penghitungan fisik persediaan. Dalam penghitungan fisik persediaan, setiap jenis persediaan dihitung dua kali secara independen
oleh
penghitung
(counter)
dan
pengecek
67 (checker). Kartu penghitungan fisik dibagi menjadi tiga bagian, yang tiap bagian dapat dipisahkan satu dengan yang lainnya dengan cara menyobeknya pada waktu proses penghitungan fisik (bagian bawah) disediakan untuk merekam data hasil penghitungan oleh penghitung pertama. Bagian ke-2 (bagian tengah) kartu tersebut digunakan untuk merekam hasil penghitungan
yang
dilakukan
oleh
penghitung
kedua
(pengecek). Bagian ke-1 (bagian atas) kartu tersebut digunakan dengan cara menggantungkan bagian kartu tersebut pada tempat penyimpanan barang yang bersangkutan. m. Daftar hasil penghitungan fisik Dokumen ini digunakan untuk meringkas data yang telah direkam ke dalam bagian ke-2 kartu penghitungan fisik.
