BAB 2 LANDASAN TEORI

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1. Pendekatan Basis Data 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

2 penambahan, pengambilan dan modifikasi data dapat dilakukan dengan mudah dan terkontrol 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.

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

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

5 12 b. Melakukan tugas manajemen basis data, seperti memasukan, memodifikasi dan menghapus data dari relasi yang ada. c. Melakukan query yang sederhana dan rumit 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 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 Fourth Generation Language Menurut Connolly (2010) 4GL adalah non-procedural. User mendefinisikan apa yang akan dibuat, bukan bagaimana. 4GL

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

7 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 komunikasi. Sebuah DBMS harus mampu terintegrasi dengan software 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.

8 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 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:

9 16 Gambar 2.1. Database lifecycle (Connolly 2010) 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

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

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

12 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 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

13 desain database yang lebih rumit dengan jumlah atribut yang lebih besar. 20 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.

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

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

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

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

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

19 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 Entity Types Menurut Connolly (2010) entity types adalah grup dari objek dengan sifat yang sama, yang diidentifikasikan oleh perusahaan dengan mempunyai keberadaan yang independen 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.

20 27 Menurut Connolly (2010) hubungan rekursif adalah tipe relationship dimana tipe entitas yang sama berpartisipasi lebih dari satu kali dengan peran yang berbeda 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 entitas. Atribut yang memiliki nilai tunggal untuk setiap kejadian dan tipe d. Multi valued attribute entitas. Atribut yang memiliki nilai banyak untuk setiap kejadian dan tipe

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

22 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

23 atribut primary key dari entitas Staff dan PropertyForRent, yang dinamakan staffno dan propertyno. 30 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 yang artinya hanya satu entity occurence.

24 31 0..* yang artinya nol atau lebih entity occurence. 1..* yang artinya satu atau lebih entity occurence 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.

25 Metodologi Perancangan Basis Data Dalam penyusunan skripsi ini menggunakan metode perancangan basis data diantaranya adalah: 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.

26 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

27 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

28 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 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

29 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

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

31 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 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:

32 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

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

34 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

35 direalisasikan. Beberapa sistem menawarkan fasilitas keamanan yang berbeda dengan yang lain. 42 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 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 Tujuan Normalisasi Tujuan normalisasi adalah untuk mengidentifikasi sebuah kumpulan hubungan yang cocok yang mendukung kebutuhan data dari perusahaan.

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

37 Tools Yang Digunakan Tools yang digunakan dalam penulisan skripsi ini adalah Diagraming Tools dan Pemahaman Obyek Teori Diagraming Tools Diagraming Tools yang digunakan adalah sebagai berikut: 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)

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

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

40 Software Tools Mengenai software tools O Brien (2008) membahas bahasa pemrograman memungkinkan pemrogram untuk 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 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 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

41 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 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 skripsi. Penjelasan yang mengenai obyek studi yang berhubungan dengan topik 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:

42 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 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 melaksanakan penyerahan barang kepada pelanggan.

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

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

45 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 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

46 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 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 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

47 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

48 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 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 prosedur ini, fungsi gudang mengajukan permintaan pembelian dalam dalam 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

49 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

50 57 pembelian dan menyelenggarakan pencatatan utang atau mengarsipkan dokumen sumber sebagai catatan utang 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.