8
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
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.
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.
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:
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.1Data 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.2Data 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.3Fourth Generation Language
Menurut Connolly (2010) 4GL adalah non-procedural. User mendefinisikan apa yang akan dibuat, bukan bagaimana. 4GL
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.
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.
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:
Gambar 2.1. Database lifecycle (Connolly 2010) 2.1.5.1Database 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
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.2System 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.
2.1.5.3Requirement 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.
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.4Database 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
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.
2.1.5.5DBMS 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.6Application 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.
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.7Prototyping
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.
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.8Implementation
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.
2.1.5.9Data 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.
2.1.5.11 Operational Maintenance
Pendapat Connolly (2010) tentang arti operational maintenance yaitu suatu proses memonitor dan memelihara database yang telah di-install.
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
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.1Entity 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.2Relationship 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.
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.3Attributes
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.
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.
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
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.
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.
2.1.7 Metodologi Perancangan Basis Data
Dalam penyusunan skripsi ini menggunakan metode perancangan basis data diantaranya adalah:
2.1.7.1Perancangan 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.
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
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
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.2Perancangan 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
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
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.
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.3Perancangan 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 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
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.
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
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.1Tujuan Normalisasi
Tujuan normalisasi adalah untuk mengidentifikasi sebuah kumpulan hubungan yang cocok yang mendukung kebutuhan data dari perusahaan.
2.1.8.2Proses 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 non-primary 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.
2.2Tools 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.1State 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
Gambar 2.7 Notasi State Transition Diagram (STD) State 1
State 2 Kondisi
2.2.1.2Data 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 elemen-elemen DFD, diantaranya:
a. Environmental elements
Unsur lingkungan yang ada di luar batas sistem. Unsur-unsur 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.
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.
2.2.2 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.
2.2.2.1MySQL
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.2HTML
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
(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.3PHP
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.3Pemahaman 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:
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.1Fungsi 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.
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.
2.3.1.2Jaringan 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.
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.3Dokumen 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
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.1Fungsi 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
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
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.2Jaringan 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
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
pembelian dan menyelenggarakan pencatatan utang atau mengarsipkan dokumen sumber sebagai catatan utang.
2.3.2.3Dokumen 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.
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.
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.1Fungsi 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.
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.2Jaringan 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
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.
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
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.3Dokumen pada sistem persediaan
Dokumen merupakan bukti untuk merekam terjadinya transaksi yang dilakukan oleh perusahaan.Adapun dokumen yang digunakan dalam sistem persediaan, antara lain:
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.
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
