7 BAB 2 LANDAS AN TEORI
2.1
Teori Umum 2.1.1 Pengertian Basis Data Pengertian sistem basis data menurut Connoly (2002, hal 14), “Database is a shared collection of logically related data, and description of these data, design to meet the information needs of an organization”, dapat diartikan sebagai sistem basis data adalah sekumpulan data yang saling berelasi secara logika dan deskripsi data ini dirancang untuk memenuhi informasi dalam sebuah organisasi. Pengertian sistem basis data menurut C.J Date (2000, hal 5), “A database system is basically a computerized records keeping system, it is a computerized system whose overall purpose is to store information and to allow users to retrieve and update that information on demand”, dapat diartikan sebagai sistem basis data pada dasarnya sebuah sistem yang menyimpan data-data komputer yang merupakan sistem terkomputerisasi dan bertujuan untuk menyimpan informasi dan mengijinkan user untuk mendapatkan kembali dan
mengubah
informasi
berdasarkan permintaan. Dari pengertian tersebut penulis menyimpulkan bahwa sistem basis data adalah sebuah sistem yang menyimpan sekumpulan data di mana entitas-entitas tersebut saling berelasi sehingga memudahkan user dalam pengaksesan data sesuai dengan permintaan user.
8 2.1.2 Database Lifecycle
Databas e planning
System definition
Requirements colection and analy sis
Database design Conceptual database design DBMS selection Logical database design
Application design
P hysical database design
P rototyping ( optional )
Implementation
Data conversion and loading
Testing
Operational maintenance
Gambar 2.1 Database Life Cycle
9 2.1.2.1 Database Planning M enurut Connoly (2002, hal 273), database planning adalah kegiatan manajemen yang mengizinkan daur hidup sistem basis data untuk bekerja seefisien dan seefektif mungkin. Tahapan utama paling penting didalam database planning ini adalah mendefinisikan mission statement dan mission objectives dari proyek sistem basis data. Mission statement mendefinisikan tujuan utama dari aplikasi sistem basis data. Mission statement membantu dalam menjelaskan tujuan proyek sistem basis data dan menyediakan alur yang jelas dalam pembuatan aplikasi sistem basis data seefisien dan seefektif mungkin. Setelah mission statement didefinisikan, kegiatan selanjutnya mengidentifikasikan mission objectives. Mission Objectives diidentifikasikan sebagai sebuah tugas tertentu yang harus disediakan oleh sistem basis data.
2.1.2.2 S ystem Definition M enurut Connoly (2002, hal 274), system definition bertujuan untuk menspesifikasi jangkauan dan batasan dari aplikasi sistem basis data, user dan bagian aplikasi. M aksudnya sebelum memulai dalam merancang aplikasi sistem
basis
data,
hal
paling
mendasar
yang
dilakukan
adalah
mengidentifikasikan terlebih dahulu batas sistem yang kita bangun dan bagaimana sistem tersebut dapat berinteraksi dengan bagian yang lain dari sistem informasi sebuah organisasi.
10 2.1.2.3 Requirements Collection and Analysis M enurut Connolly (2002, hal 276), requirements collection and analysis adalah kumpulan tentang analisis informasi perusahaan yang dapat mendukung
sistem
basis
data
dan
dapat
digunakan
untuk
mengidentifikasikan kebutuhan untuk sistem yang baru. Informasi yang dikumpulkan untuk setiap user view ( yaitu peran kerja atau area aplikasi perusahaan ), yaitu : 1. deskripsi data yang digunakan 2. rincian mengenai bagaimana data digunakan 3. beberapa kebutuhan tambahan yang lain untuk aplikasi sistem basis data yang baru. Di samping itu, ada 3 pendekatan untuk mengelola kebutuhan aplikasi sistem basis data dengan banyak user, diantaranya : a. Pendekatan Terpusat Kebutuhan untuk setiap user view untuk digabung kedalam sebuah kebutuhan untuk aplikasi sistem basis data yang baru. b. Pendekatan View Integration Kebutuhan untuk setiap user view digunakan untuk membangun model data terpisah untuk merepresentasikan user view tersebut. Hasil model data akan digabungkan nantinya pada tahapan perancangan sistem basis data ( Database Design ). c. Kombinasi kedua pendekatan di atas
11 2.1.2.4 Database Design M enurut Connoly (2002, hal 279), database design adalah proses untuk menciptakan sebuah rancangan yang mendukung mission statement dan mission objective perusahaan untuk mendukung kebutuhan sistem basis data. Proses perancangan ini dibagi menjadi 3 tahap yaitu : 1. Perancangan sistem basis data konseptual M enurut Connoly (2002, hal 419) , perancangan sistem basis data konseptual adalah proses membangun sebuah model informasi yang digunakan di dalam perusahaan dengan mempertimbangkan semua fisikal. 2. Perancangan sistem basis data logikal M enurut Connoly (2002, hal 419), perancangan sistem basis data logikal adalah suatu proses membangun sebuah model informasi yang digunakan dalam sebuah perusahaan berdasarkan sebuah model spesifik tetapi bebas dari Database Management System dan mempertimbangkan fisikal lainnya. 3. Perancangan sistem basis data fisikal M enurut Connoly (2002, hal 419), perancangan sistem basis data fisikal adalah suatu proses menghasilkan deskripsi dari implementasi sistem basis data pada media sekunder yang menggunakan relasi dasar, organisasi file, dan indeks yang digunakan untuk mengakses data seefisien mungkin dan beberapa integritas data serta ukuranukuran keamanan.
12
2.1.2.5 Database Management System Selection M enurut Connoly (2002, hal 284), DBM S selection yang mendukung aplikasi sistem basis data. Tahapan utama dalam pemilihan DBM S yaitu : 1. mendefinisikan persyaratan dari referensi pemilihan DBM S 2. membuat daftar dua atau tiga buah produk 3. mengevaluasi masing-masing produk 4. rekomendasi pemilihan dan laporannya
2.1.2.6 Application Design M enurut Connoly (2002, hal 287), application design digunakan untuk merancang tampilan user dan aplikasi program yang diterapkan serta proses dari sistem basis data.
2.1.2.7 Prototyping (Optional) M enurut Connoly (2002, hal 291), prototyping membangun sebuah model kerja aplikasi sistem basis data, yang mana mengijinkan perancang atau user untuk memvisualisasi dan mengevaluasi bagaimana tampilan akhir yang akan dihasilkan. Tujuan utama pengembangan sebuah protyping pada aplikasi sistem basis data adalah mengijinkan user untuk mengunakan prototype untuk mengidentifikasi keunggulan dari sebuah sistem yang bekerja dengan baik.
13 2.1.2.8 Implementation M enurut Connoly (2002, hal 292), implementation menciptakan sebuah sistem basis data yang fisik dan aplikasi perancangannya.
2.1.2.9 Data Conversion and Loading M enurut Connoly (2002, hal 292), data conversion and loading adalah memindahkan data dari sistem basis data yang lama ke sistem basis data yang baru dan mengkonversi aplikasi yang lama untuk dijalankan pada sistem basis data yang baru.
2.1.2.10 Testing M enurut Connoly (2002, hal 293), aplikasi sistem basis data diuji untuk mengetes kesalahan dan memvalidasi kembali kebutuhan lebih spesifik para user.
2.1.2.11 Operational Maintenance M enurut
Connoly
(2002, hal 293),
operational maintenance
merupakan proses untuk mengawasai dan merawat selama sistem dijalankan.
2.1.3 Entity Relationship Modelling 2.1.3.1 Tipe Entitas M enurut Connoly (2002, hal 331), tipe entitas adalah sekumpulan objek dengan properti yang sama yang diidentifikasi oleh perusahaan.
14 Representasi diagramatik dari entitas :
Gambar 2.2 Representasi diagramatik tipe entitas S taff dan Branch
2.1.3.2 Tipe Hubungan M enurut Connoly (2002, hal 334), tipe hubungan adalah adalah sekumpulan entitas yang memiliki hubungan satu sama lain. Relationship
Occurence
adalah
suatu
gabungan
yang
dapat
diidentifikasikan secara unik yang meliputi suatu kejadian dari setiap tipe entitas yang berpartisipasi.
Gambar 2.3 Representasi tipe hubungan Branch memiliki S taff
15 2.1.3.3 Atribut M enurut Connoly (2002, hal 338), ”Attribute is a property of an entity or a relationship type”, dapat diartikan sebagai atribut adalah sebuah properti dari sebuah entitas atau tipe relasi. Atribut terdiri dari : 1. Simple dan Composite attributes Simpel attribute adalah sebuah atribut yang terdiri dari komponen tunggal dengan keberadaan independen (tetap). Atribut simpel kadang disebut juga komponen atomik (tidak bisa dibagi). Composite attribute adalah sebuah atribut yang terdiri dari banyak komponen dengan keberadaan independen (tetap). 2. Single-Valued and Multi-Valued Attributes Single-valued attribute adalah sebuah atribut yang memiliki nilai tunggal untuk masing-masing kejadian dari sebuah entitas. Multi-valued attribute adalah atribut yang memiliki banyak nilai untuk masing-masing kejadian dari sebuah entitas. 3. Derived Attributes Derived attribute adalah atribut yang menggantikan sebuah nilai yang diturunkan dari nilai atribut yang berhubungan atau kumpulan dari atribut, tidak perlu pada jenis entitas yang sama.
16 2.1.3.4 Key 1. Candidate Key M enurut Connoly (2002, hal 340) candidate key adalah kunci yang secara unik atau tidak mungkin kembar atau berbeda dengan yang lain, dapat dipakai untuk mengidentifikasikan satu baris dalam tipe entitas. Contoh : BranchNo adalah candidate key untuk tipe Branch (yang dipilih sebagai primary key) dimana setiap branch mempunyai sebuah BranchNo yang unik / tidak mungkin kembar.
2. Primary Key M enurut Connoly (2002, hal 341) , primary key adalah candidate
key
yang
dipilih
sebagai
kunci
primer
untuk
mengidentifikasikan setiap entitas . Contoh : StaffNo maksimum lima karakter (misal : SG16). NIN (National Insurance Number) maksimum 9 karakter (misalnya = WL220658 D) berarti primary key-nya = StaffNo, sedangkan NIN = alternate key (candidate key yang tidak dipilih sebagai primary key).
3. Composite Key M enurut Connoly (2002, hal 341), Composite Key adalah candidate key yang terdiri dari dua atau lebih atribut. Contoh
:
Atribut
=
PropertyNo,
NewspaperName,
DateAdvert, Cost. Banyak property yang diiklankan dalam banyak
17 koran pada suatu tanggal tertentu. Untuk mengidentifikasikan setiap kejadian secara unik dari entitas advert, dibutuhkan nilai pada atribut PropertyNo, NewspaperName dan DateAdvert.
2.1.3.5 S tructural Constraints (Batasan Struktural) M enurut Connoly (2002, hal 344) tipe utama dari batasan hubungan dinamakan multiplicity. Multiplicity adalah jumlah kemungkinan kejadian sebuah entitas yang mungkin berhubungan ke sebuah kejadian tunggal dari sebuah entitas yang tergabung melalui sebuah hubungan khusus. Hubungan binari secara umum dibedakan menjadi : 1. derajat hubungan one-to-one (1:1) Derajat hubungan antar entitas one-to-one ( 1:1) terjadi bila tiap anggota entitas Staff hanya boleh berpasangan dengan satu anggota dari entitas Branch. Sebaliknya tiap anggota dari entitas Branch hanya boleh berpasangan dengan satu anggota dari entitas Staff. 2. derajat hubungan one-to-many (1:*) Derajat hubungan ini terjadi bila tiap anggota entitas Staff boleh berpasangan dengan lebih dari satu anggota entitas PropertyForRent. Sebaliknya setiap anggota entitas PropertyForRent hanya boleh berpasangan dengan satu anggota entitas Staff. 3. derajat hubungan many-to-many (*:*) Derajat hubungan antar entitas ini terjadi bila tiap anggota entitas NewsPaper boleh berpasangan dengan lebih dari satu anggota entitas
18 PropertyForRent. Sebaliknya tiap anggota entitas PropertyForRent juga boleh berpasangan dengan lebih dari satu anggota entitas NewsPaper.
2.1.4 Normalisasi 2.1.4.1 Pengertian Normalisasi M enurut Connoly (2002, hal 376), “Normalization is a technique for producing a set of relations with desirable properties, given the data requirements of an enterprise”, dapat diartikan sebagai normalisasi adalah sebuah teknik yang menghasilkan sekumpulan relasi dengan kriteria yang diinginkan, yang memberikan kebutuhan data dari sebuah perusahaan.
2.1.4.2 Tahap-tahap Normalisasi Tahap-tahap normalisasi terdiri dari : 1. Unnormalized Form (UNF) M enurut Connoly (2002, hal 387) “Unnormalized form (UNF) is a table that contains one or more repeating groups”, dapat diartikan sebagai UNF adalah sebuah table yang berisikan satu atau lebih kumpulan data yang berulang (redundansi). 2. First Normal Form (1NF) M enurut Connoly (2002, hal 388) “First normal form (1NF) is a relation in which the intersection of reach row and column contains one and only one value”, dapat diartikan sebagai 1NF adalah sebuah
19 relasi yang mana titik pertemuan antara setiap baris dan kolom yang berisi satu dan hanya satu nilai. 3. Second Normal Form (2NF) M enurut Connoly (2002, hal 391) “Second Normal Form (2NF) is a relation that is in first normal form and every non-primary key attribute is fully functionally dependent on the primary key”, diartikan sebagai 2NF adalah sebuah relasi yang terdapat di dalam 1NF dan setiap atribut yang bukan primary key bergantung pada primary keynya. 4. Third Normal Form (3NF) M enurut Connoly (2002, hal 394) “Third Normal Form (3NF) is a relation that is in first and second normal form, and in which no nonprimary key attribute is transitively dependent on the primary key”. Dapat diartikan sebagai 3NF adalah sebuah relasi yang terdapat pada bentuk normalisasi pertama dan kedua, yang mana atribut primary key adalah bergantung pada primary key-nya.
2.1.5 Metodologi Perancangan Sistem Basis Data 2.1.5.1 Perancangan Sistem Basis Data Konseptual M enurut Connoly (2002, hal 419), perancangan sistem basis data konseptual adalah proses membangun sebuah model informasi yg digunakan dengan mempertimbangkan semua fisikal
Langkah 1: Perancangan sistem basis data konseptual
20 Bertujuan untuk membangun model data konseptual dari kebutuhan data perusahaan
1.1 M engidentifikasi tipe-tipe entitas Bertujuan untuk mengidentifikasikan tipe entitas yang akan dibangun. Langkah pertama dalam membangun model data konseptual adalah dengan mendefinisikan objek-objek utama user. Objek-objek ini merupakan tipe-tipe entitas untuk model tersebut. Salah satu metode mengidentifikasikan entitas adalah dengan memeriksa spesifikasi kebutuhan user dengan mengidentifikasikan kata benda. Contoh tipe entitas adalah staff, mata kuliah, dosen, mahasiswa, dan lain-lain. Seteah tipe-tipe entitas tersebut diidentifikasikan, pemberian nama untuk tiap-tiap entitas haruslah jelas bagi user. Nama dan deskripsi entitas sebaiknya disimpan pada kamus data. Jika sebuah entitas dikenal dengan nama lain yg disebut dengan sinonim atau alias, maka disimpan juga pada kamus data.
1.2 M engidentifikasi tipe-tipe hubungan antar entitas Bertujuan mengidentifikasikan relasi-relasi penting yang ada di antara tipe entitas yang sudah diidentifikasikan. Untuk mengidentifikasikan relasi dapat dilakukan dengan cara mencari kata kerja pada spesifikasi kebutuhan user. Contoh : staff manage propertyforRent, privateOwner owns PropertyForRent. Pada
21 umumnya relasi bersifat biner, yaitu relasi tersebut berada hanya diantara dua tipe entitas. Namun perlu juga diperhatikan adanya relasi kompleks yang melibatkan lebih dari tipe entitas dan relasi rekursif yang melibatkan hanya satu tipe entitas. Setelah mengidentifikasikan relasi, langkah selanjutnya adalah menentukan multiplicity setiap relasi.
Batasan multiplicity digunakan
untuk
memeriksa dan
memelihara kualitas data. Selain itu harus juga diperiksa adanya fan traps dan chasm traps dan setiap relasi harus berpartisipasi minimal satu relasi. Deskripsi relasi dan batasan-batasan multiciplity harus disimpan dalam kamus data.
1.3 M engidentifikasi dan mengasosiasikan atribut-atribut dengan tipe-tipe entitas atau hubungan antar entitas Bertujuan untuk mengidentifikasikan atribut terhadap entitas atau relasi biasanya disebut dicari kata benda atau frase kata benda dari spesifikasi kebutuhan user. Ada 3 jenis attribute yaitu : 1. simple atau composite attribute 2. single atau multivalue attribute 3. derived attribute
1.4 M enentukan domain attribut Bertujuan utnuk menentukan batasan atribut di model data konseptual lokal.
22 Domain adalah kumpulan nilai-nilai yang diizinkan untuk satu atau lebih atribut. Contoh domain untuk atribut ”Jenis Kelamin” pada tabel ”staff” adalah sebuah karakter tunggal yang yang bernilai hanya ”L” (untuk laki-laki) atau ’P” (untuk perempuan). Sebuah model data yang baik menspesifikasikan domain untuk setiap atribut dan meliputi: 1. Kumpulan nilai – nilai yang diizinkan untuk atribut 2. Ukuran dan format atribut Setelah domain atribut diidentifikasikan, nama-nama domain dan karakteristiknya disimpan pada kamus data.
1.5 M enentukan atribut candidate dan primary key Candidate key adalah kunci yang unik atau tidak mungkin kembar atau berbeda dengan yang lain, dapat dipakai untuk mengidentifikasikan satu baris dalam tipe entitas. Composite key adalah candidate key yang terdiri dari dua atau lebih atribut. Primary key adalah candidate key yang dipilih sebagai kunci primer untuk mengidentifikasikan setiap entitas. Alternate key adalah candidate key yang tidak terpilih menjadi primary key. Foreign key adalah sebuah atribut atau kumpulan atribut dalam suatu relasi yang sama dengan candidate key dari beberapa relasi (mungkin relasi yang sama).
23
1.6 M empertimbangkan penggunaan konsep enhanced modeling Bertujuan
untuk
mempertimbangkan
modeling seperti spesialisasi atau
konsep
generalisasi,
enhanced
agregasi dan
komposisi. Pada tahap ini jika memilih pendekatan spesialisasi, diusahakan untuk memperhatikan perbedaan antara entitas dengan mendefiniskan satu atau lebih subclass dari sebuah entitas superclass. Jika menggunakan
pendekatan
mengidentifikasikan
fitur-fitur
generalisasi, umum
diusahakan untuk
antar
entitas
untuk
mendefinisikan sebuah entitas superclass generalisasi. Pendekatan agregasi digunakan untuk merepresentasikan hubungan ”mempunyai suatu” atau ”bagian dari” antara tipe-tipe entitas, dimana yang satu merepresentasikan
”keseluruhan”
dan
yang
lainnya
sebagai
”bagiannya”. Komposisi digunakan untuk merepresentasikan sebuah asosiasi antara tipe-tipe entitas dimana terdapat kepemilikan yang kuat dan keterhubungan antara ”keseluruhan” dan ”bagiannya”.
1.7 M emeriksa model terhadap redundansi Bertujuan untuk memeriksa adanya redundansi pada model. Ada 2 aktifitas pada tahap ini, yaitu: 1. M emeriksa kembali relasi one-to-one ( 1:1) Pada
saat
mengidentifikasi
entitas,
mungkin
akan
teridentifikasi dua entitas yang merepresentasikan objek yang sama pada perusahaan. Untuk kejadian ini, kedua entitas
24 tersebut harus digabungkan . Jika primary key beberda, pilih salah satu primary key tersebut dan biarkan yang lain sebagai alternate key.
2. M enghilangkan relasi yang redundansi Suatu relasi dikatakan dedundansi jika informasi yang sama dapat diperbolehkan melalui relasi yang lain. Data model yang baik seminimal mungkin tidak memiliki relasi yang redundan.
1.8 M emvalidasikan model konseptual lokal terhadap transaksi user. Bertujuan
untuk
memastikan
bahwa
model konseptual
mendukung kebutuhan transaksi yang diperlukan bagi view. Dua pendekatan yang mungkin dilakukan untuk memastikan bahwa model data konseptual lokal mendukung transaksi yang dibutuhkan adalah : 1. M endeskripsikan transaksi M emeriksa apakah semua informasi (entitas, relasi, dan attributnya) yang dibutuhkan oleh setiap transaksi telah disediakan oleh model, dengan mendokumentasikan sebuah deskripsi dari kebutuhan transaksi. 2. M emakai jalur transaksi M emvalidasi model data terhadap transaksi yang dibutuhkan yang melibatkan diagram yang merepresentasikan jalur setiap transaksi dalam diagram ER.
25 1.9 M eninjau kembali model data konseptual dengan pengguna. Bertujuan untuk meninjau kembali model data konseptual lokal dengan user untuk memastikan bahwa model representasi telah sesuai. Pada langkah ini data konseptual lokal ditinjau ulang oleh user. M odel data konseptual meliputi diagram ER dan dokumentasi pendukung yang menggambarkan model data tersebut. Jika terjadi anomali pada model data, maka harus dilakukan perubahan yang mungkin memerlukan pengulangan langkah-langkah sebelumnya. Proses ini terus diulang sampai model data benar-benar menjadi representasi aktual dari perusahaan.
Gambar 2.4 Contoh Entity Relationship Diagram Konseptual
26 2.1.5.2 Perancangan Sistem Basis Data Logikal M enurut Connoly (2002, hal 419) , perancangan sistem basis data logikal adalah suatu proses membangun model informasi yang digunakan dalam sebuah perusahaan berdasarkan sebuah model spesifik tetapi bebas dari Database Management System dan mempertimbangkan fisikal lainnya.
Langkah 2: M embangun dan memvalidasi model data logikal lokal untuk setiap view. Bertujuan untuk membangun model data logikal dari model data konseptual lokal yang merepresentasikan view tertentu dari perusahaan dan memvalidasikan model tersebut untuk menjamin agar strukturnya benar (menggunakan
teknik
normalisasi)
dan
mendukung transaksi yang
dibutuhkan.
2.1 M emperoleh relasi untuk model data logikal lokal Bertujuan untuk membangun relasi untuk model data logikal lokal untuk merepresentasi entitas, relasi dan attribut yang telah diidentifikasikan. Pembagian relasi yang dapat dihasilkan dari sebuah model data diantaranya : -
tipe entitas kuat
-
tipe entitas lemah
-
tipe relasi binari one-to-one ( 1:1)
-
tipe relasi one to many ( 1:*)
27 -
tipe relasi many to many ( *:*)
-
tipe relasi superclass/subclass
-
tipe relasi kompleks
-
attribut multivalue
2.2 M emvalidasikan relasi menggunakan normalisasi Bertujuan untuk memvalidasikan relasi di dalam model data logikal lokal menggunakan teknik normalisasi. Proses normalisasi terdiri dari Unnormal Form ( UNF ), First Normal Form ( 1NF ), Second Normal Form ( 2NF) dan Third Normal Form (3NF).
2.3 M emvalidasikan relasi terhadap transaksi pengguna Bertujuan untuk memastikan bahwa relasi di dalam model data logikal lokal mendukung kebutuhan transaksi bagi view. Validasi transaksi seperti ini sudah dilakukan pada langkah 1.8 namun dilakukan kembali untuk mengecek relasi-relasi yang diciptakan pada rancangan logikal juga mendukung transaksi user.
2.4 M engecek batasan integritas Bertujuan
untuk
mengecek
batas
direpresentasikan ke dalam model data logikal. Ada 5 tipe batasan integritas yaitu : 1. Data yang dibutuhkan
integritas
yang
28 Beberapa atribut harus memiliki sebuah nilai yang valid (tidak mengandung NULL). Contoh : setiap anggota staff harus memiliki hubungan posisi jabatan (seperti supervisor atau asisten). 2. Batasan domain atribut Setiap attribute memiliki sebuah domain. Dengan kata lain sekumpulan nilai harus sah. Contoh : jenis kelamin untuk anggota staff boleh ”M ” atau ”F”, jadi domain atribut untuk jenis kelamin adalah karakter tunggal. Batasan ini harus diidentifikasi dalam kamus data. 3. Integritas Entitas Primary key dari sebuah entity tidak boleh NULL. Contoh setiap baris dari relasi staff harus memiliki nilai untuk attribut primary key. 4. Integritas Referensial Foreign key menghubungkan setiap baris dari relasi anak untuk baris ke dalam relasi induk dengan mencocokan kandidat keynya. Referential Integrity maksudnya adalah jika foreign key berisi sebuah nilai yang nilainya harus menunjukkan baris yang ada pada relasi induknya. 5. Batasan perusahaan Terakhir, kita memperhatikan batasan perusahaan. M engupdate entitas mungkin dikontrol oleh yang memiliki hak pembatas.
29 2.5 M eninjau kembali model data logikal lokal dengan user Bertujuan untuk memastikan bahwa model data logikal lokal dan dokumen pendukung yang mendeskripsikan model yang sesuai dengan view. M odel data logikal telah selesai dan didokumentasikan. Pada tahapan ini model logikal dan dokumentasi tersebut ditinjau ulang dengan user.
2.6 M enggabungkan model data logikal ke dalam global Bertujuan untuk menggabungkan model data logikal lokal ke dalam model data logikal global yang merepresentasikan semua user view dari sebuah sistem basis data. Kegiatan dalam tahapan ini terdiri dari : 1. menggabungkan model data logikal lokal ke dalam model global. 2. memvalidasikan model data logikal global. 3. meninjau kembali model data logikal global dengan user.
2.7 M engecek untuk perkembangan masa yang akan datang Bertujuan untuk menentukan apakah ada perubahan dan menilai apakah model data logikal bisa menampung perubahan ini. Perancangan sistem basis data logikal sangat memperhatikan apakah
model data logikal (boleh
atau
tidak
boleh
untuk
30 dikembangkan berdasarkan langkah 2.6) yang digunakan untuk mendukung perkembangan di masa akan datang.
Gambar 2.5 Contoh Entity Relationship Diagram Logikal
31 2.1.5.3 Perancangan Sistem Basis Data Fisikal M enurut Connoly (2002, hal 419), Perancangan sistem basis data fisikal adalah suatu proses menghasilkan deskripsi dari implementasi sistem basis data pada media sekunder yang menggunakan relasi dasar, organisasi file dan indeks yang digunakan untuk mengakses data seefisien mungkin dan beberapa integritas data serta batasan keamanannya.
Langkah 3: M enerjemahkan model data logikal global untuk target DBM S. Bertujuan untuk menghasilkan skema basis data relasional dari model data logikal global yang dapat diimplementasikan pada DBM S pilihan. Bagian pertama dari proses ini memerlukan perbandingan informasi yang dikumpulkan
selama
perancangan
sistem
basis
data
logikal
dan
didokumentasikan pada kamus data. Bagian kedua dari proses ini menggunakan infromasi tersebut untuk menghasilkan desain relasi dasar. Proses ini memerlukan pengetahuan yang mendalam mengenai fungsionalitas yang ditawarkan oleh DBM S pilihan.
M erancang relasi dasar Bertujuan
untuk
memutuskan
bagaimana
relasi
dasar
diidentifikasikan pada model data logikal global ke dalam target DBM S. Untuk memulai perancangan fisikal pertama kita harus menyusun dan memahami informasi tentang relasi yang menghasilkan perancangan sistem basis data logikal. Kebutuhan informasi ini bisa
32 berupa kamus data dan definisi relasi yang menggambarkan penggunaan database design language ( DBDL ).
M erancang representasi dari data yang telah didapat Bertujuan untuk memutuskan bagaimana merepresentasikan semua data yang telah didapat pada data logikal global ke dalam DBM S pilihan. Atribut yang nilainya dapat diperoleh dengan memeriksa nilai dari atribut lain disebut atribut yang didapat atau atribut hasil kalkulasi. Langkah pertama adalah memeriksa model data logikal dan kamus data untuk menghasilkan daftar semua atribut yang didapat. Pada perancangan sistem basis data fisikal, atribut yang telah diperoleh dapat disimpan ke dalam sistem basis data atau dikalkulasikan setiap kali diperlukan. Perancang harus memperhatikan biaya tambahan untuk menyimpan data yang telah diperoleh dan menjaganya agar tetap konsisten dengan data operasional dari mana data tersebut diperoleh atau biaya untuk mengkalkulasikan atribut tersebut setiap kali diperlukan.
M erancang batasan perusahaan Bertujuan untuk merancang batasan perusahaan pada DBM S pilihan.
33 Perubahan terhadap data dapat dibatasi oleh aturan perusahaan yang mengatur transaksi dalam ”dunia nyata.” Perancangan batasan ini tergantung pada pemilihan DBM S yang akan digunakan. Beberapa DBM S menyediakan fasilitas ini namun ada juga yang tidak menyediakannya, sehingga untuk menentukan batasan harus dilakukan pada progam aplikasi.
Langkah 4 : Perancangan sistem basis data fisikal Bertujuan untuk menentukan optimal organisasi file untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk mencapai hasil yang baik yaitu dengan cara yang mana relasi dan baris akan dipegang ditempat penyimpanan sekunder.
4.1 M enganalisis transaksi Bertujuan untuk memahami fungsi transaksi yang akan dijalankan pada sistem basis data dan analisis transaksi yang penting. Dalam analisis transaksi terdapat beberapa kriteria diantaranya: 1. Transaksi yang sering dijalankan akan memiliki pengaruh yang penting pada hasil. 2. Transaksi yang kritis untuk beroperasi pada bisnis. 3. Waktu
selama
harian
atau
mingguan
ketika
meningkatkan permintaan pada sistem basis data.
dapat
34 4.2 M emilih organisasi file Bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Salah satu tujuan utama dalam perancangan sistem basis data fisikal adalah untuk menyimpan dan mengakses data dengan jalur yang efisien.
4.3 M emilih indeks Bertujuan untuk menentukan apakah penambahan indeks akan meningkatkan performa dari sistem. Kriteria memilih atribut untuk ordering atau clustering tuple antara lain : a. Atribut yang paling sering digunakan untuk operasi join sehingga operasi join tersebut mejadi lebih efisien atau b. Atribut yang sering digunakan untuk mengakses tuple pada sebuah tabel berdasarkan urutan atribut tersebut. Jika urutan ordering yang dipilih adalah key dari tabel, indeks akan menjadi primary index. Namun jika bukan index key akan menjadi clustering index. Indeks sekunder menyediakan sebuah mekanisme untuk menspesifikasikan key tambahan untuk relasi dasar yang dapat digunakan untuk mengambil data lebih efisien. Beberapa pertambahan dalam menggunakan indeks sekunder meliputi:
35 a. M enambahkan sebuah indeks record untuk setiap indeks sekunder setiap kali sebuah tuple dimasukan ke dalam sebuah tabel. b. M engupdate indeks sekunder ketika tuple yang bersangkutan pada tabel tersebut diubah. c. Penambahan kapasitas disk untuk menyimpan indeks sekunder. d. Kemungkinan penurunan performa selama optimasi query karena query optimizer mempertimbangkan semua indeks sekunder sebelum memilih strategi eksekusi yang optimal.
4.4 M emperkirakan kebutuhan kapasitas disk Bertujuan untuk memperkirakan jumlah kapasitas disk yang dibutuhkan oleh sistem basis data. M emperkirakan penggunaan kapasitas disk tergantung pada DBM S yang dipakai dan perangkat keras yang digunakan untuk mendukung sistem basis data. Secara umum estimasi didasarkan pada ukuran setiap baris dan jumlah baris dalam setiap tabel. Selain itu perlu juga dipertimbangkan apakah setiap tabel akan bertumbuh dan sebaiknya akan faktor pertumbuhan ini dimasukan ke dalam perhitungan kebutuhan kapasitas disk.
36 Langkah 5 : M erancang User View Bertujuan untuk merancang user view yang diidentifikasi selama tahapan pengumpulan kebutuhan dan analisis dari siklus aplikasi sistem basis data. User view mendefinisikan apa yang dibutuhkan dari aplikasi sistem basis data dari sudut pandang jabatan tertentu (misalnya manajer atau supervisor) atau area aplikasi perusahaan (seperti pemasaran, personalia atau pengendalian stok). Perancangan dari user view individual harus didokumentasikan secara lengkap.
Langkah 6 : M erancang mekanisme keamanan. Bertujuan untuk merancang mekanisme keamanan untuk sistem basis data yang dispesifikasi oleh user. -
Keamanan sistem M eliputi akses dan penggunaan sistem basis data pada tingkatan sistem seperti username dan password.
-
Keamanan data M eliputi akses dan penggunaan objek sistem basis data (seperti relasi dan view) dan tindakan yang memungkinkan user untuk memanipulasi objek.
37 Langkah 7: M empertimbangkan penggunaan dari redundansi kontrol Bertujuan untuk menentukan apakah penerapan redundansi dalam situasi terkontrol dengan mengurangi aturan normalisasi akan meningkatkan performa sistem. Seringkali rancangan sistem basis data yang ternormalisasi tidak mampu menyediakan efisiensi pemrosesan yang maksimum sehingga denormalisasi dilakukan untuk mencapai performa yang diinginkan. Namun yang perlu dipertimbangkan beberapa faktor berikut : a. denormalisasi menyebabkan implementasi menjadi lebih kompleks. b. denormalisasi seringkali mengurangi fleksibilitas. c. denormalisasi
dapat
mempercepat
pengambilan
data
namun
memperlambat update.
Denormalisasi untuk mempercepat transaksi yang sering dilakukan atau transaksi kritis dapat diaplikasikan pada situasi berikut : 1. M enggabungkan one-to-one ( 1:1) M enguji kembali relasi one-to-one (1:1) menentukan efek dari kombinasi relasi ke dalam relasi tunggal. Kombinasi seharusnya hanya memperhatikan untuk relasi yang sering direlasi dan yang tidak sering direlasikan. 2. M enduplikasikan atribut-atribut yang bukan kunci di dalam relasi oneto-many (1:*) untuk mengurangi join. 3. M enduplikasi atribut-atribut foreign key di dalam relasi one-to-many (1:*)
38 4. M enduplikasikan atribut dalam many-to-many (*:*) relasi untuk mengurangi join. 5. M empelajari kelompok repetisi 6. M embuat tabel kutipan 7. M embagi relasi
Langkah 8 : M engawasi dan menggunakan sistem operasional Bertujuan untuk mengawasi sistem operasional dan meningkatkan performa sistem untuk memperbaiki keputusan rancangan yang kurang tepat atau adanya perubahan kebutuhan. Perancangan awal sistem basis data secara fisikal seharusnya tidak dianggap statis, melainkan harus dipertimbangkan sebagai sebuah perkiraan dari kinerja operasional. Setelah perancangan awal telah diimplementasikan, maka diperlukan pengawasan sistem dan penyetelannya sebagai hasil dari pengamatan kinerja dan perubahan kebutuhan.
2.1.6 Data Flow Diagram M enurut Whitten (2004, hal 334), “Data Flow Diagram ( DFD) is a tool that depicts the flow of data through a system and the work or processing performed by that system”, dapat diartikan sebagai DFD adalah sebuah alat yang menggambarkan aliran data sampai sebuah sistem selesai dan kerja atau proses dan dilakukan dalam sistem tersebut. Sinonimnya adalah bagan bubble, grafik transformasi, and model proses. Ada 4 komponen dalam DFD yaitu:
39 1. External Agent M enurut Whitten (hal 363), “External agents are define a person, an organization unit, another system or another organizatoin that lies outside the scope of the project but that interacts with the system being studied”, dapat diartikan sebagai external agent adalah mendefinisikan orang, sebuah unit organisasi , sistem lain atau organisasi lain yang berada di luar sistem projek tetapi yang mempengaruhi kerja sistem. M enurut Whitten (hal 347) ada beberapa bentuk external agent : a. bentuk Gain dan Sarson (digunakan dalam skripsi ini)
Gambar 2.6 Bentuk External Agent Berdasarkan Gain dan S arson
b. bentuk DeM arco/Yourdon
Gambar 2.7 Bentuk External Agent Berdasarkan DeMarco/Yourdon
c. bentuk SSADM /IDEF0
Gambar 2.8 Bentuk External Agent Berdasarkan SS ADM/IDEF0
40
2. Process M enurut Whitten (hal 347), ”Process is a work perform on , all in response , incoming data flows or condition”, dapat diartikan sebagai proses adalah penyelenggaraaan kerja atau jawaban, datangnya aliran data atau kondisinya. M enurut Whitten (hal 347) ada beberapa bentuk proses diantaranya : a. Bentuk Gain and Sarson
Gambar 2.9 Bentuk Proses Berdasarkan Gain dan S arson
b. bentuk DeM arco/Yourdon
Gambar 2.10 Bentuk Proses Berdasarkan DeMarco/Yourdon
c. bentuk SSADM /IDEF0
Gambar 2.11 Bentuk Proses Berdasarkan SS ADM/IDEF0
41 3. Data Stores Data Stores is an “inventory” of data , dapat diartikan sebagai data store adalah tempat penyimpanan data. M enurut Whitten (hal 366) ada beberapa bentuk data stores diantaranya: Bentuk Gain and Sarson
Gambar 2.12 Bentuk Data Store Berdasarkan Gain dan S arson
a. Bentuk DeM arco/Yourdon
Gambar 2.13 Bentuk Data Store Berdasarkan DeMarco/Yourdon
b. Bentuk SSADM /IDEF0
Gambar 2.14 Bentuk Data Store Berdasarkan SS ADM/IDEF0
4. Data Flow Data Flow is represents an input of data to a process or the output of data (or information) from a process, dapat diartikan sebagai data flow
42 adalah merepresentasikan sebuah input data ke dalam sebuah proses atau output dari data (atau informasi) dari sebuah proses. Bentuk data flow : Nama data flow
Jenis-jenis DFD adalah sebagai berikut : 1.
Level 0 (Diagram Context) Level ini terdapat sebuah proses yang berada di posisi pusat.
2.
Level 1 (Diagram Nol) Level ini merupakan sebuah proses yang terdapat di level nol yang dipecahkan menjadi beberapa proses lainnya.
3.
Level 2 (Diagram Rinci) Pada level ini merupakan diagram yang merincikan diagram dari level 1. •
Tanda ’*’ digunakan hanya jika proses tersebut tidak bisa dirincikan lagi. Contoh : 2.0*, artinya proses level rendah yang tidak bisa dirincikan lagi.
•
Penomeran yang dilakukan berdasarkan urutan proses.
2.1.7 S tate Transition Diagram State Transition Diagram (STD) adalah sebuah perangkat pemodelan yang menggambarkan sifat ketergantungan terhadap waktu pada sistem. M enurut Pressman
(2001,
hal 317),
STD
digunakan
untuk
mengidentifikasikan
43 sebagaimana sistem harus berperilaku seperti resiko dari kejadian eksternal. Untuk mencapai hal ini STD menampilkan berbagai jenis model perilaku dari hasil dan tingkah laku yang mana transisi dibuat dari satu step ke step yang lain. Penyajian STD merupakan landasan dasar untuk menentukan perilaku. Biasanya di dalam STD digunakan notasi seperti : 1. Active •
State, simbolnya persegi panjang State adalah kumpulan keadaan atau atribut yang memberi perincian seseorang atau benda pada waktu dan kondisi tertentu. Contohnya seperti : Proses user mengisi password, menentukan instruksi berikutnya. Simbol state :
•
Transition State / Perubahan State, simbolnya tanda panah berarah. Simbol transition state :
•
Condition Kejadian pada lingkungan eksternal yang bisa terdeteksi oleh sistem Hal ini akan mengakibatkan perubahan pada state dari keadaan state menunggu X ke state menunggu Y. Contohnya seperti interupt signal maupun data.
44 •
Action Action adalah hal yang dilakukan sistem apabila ada perubahan state atau merupakan reaksi terhadap kondisi. Action menghasilkan keluaran dari tampilan pesan, cetakan atau alat output lainnya.
2. Passive Sistem ini tidak melakukan kontrol terhadap lingkungan, akan tetapi lebih bersifat menerima data atau memberi reaksi saja (sistem yang menerima atau mengumpulkan data dari sinyal yang dikirim oleh satelit ). Berikut adalah gambar STD yang sederhana : State X
State Y
Gambar 2.15 Contoh State Transition Diagram yang S ederhana
2.2
Teori Khusus 2.2.1 Pembelian M enurut M ulyadi (2001, hal 299) sistem akuntansi pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan.
45 Transaksi pembelian dapat digolongkan menjadi dua : pembelian lokal dan impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri, sedangkan impor adalah pembelian dari pemasok luar negeri. M enurut M ulyadi (2001, hal 299), fungsi yang terkait dalam sistem akuntansi pembelian adalah : 1. Fungsi Gudang Dalam sistem akuntansi pembelian, fungsi gudang bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang untuk menyimpan barang yang telah diterima oleh fungsi penerimaan.
Untuk
barang-barang
yang
langsung
pakai
(tidak
diselenggarakan persediaan barang di gudang), permintaan pembelian diajukan oleh pemakai barang. 2. Fungsi pembelian Fungsi pembelian bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. 3. Fungsi penerimaan Dalam sistem akuntansi pembelian, fungsi ini bertanggung jawab untuk melakukan pemeriksaan terhadap jueni, mutu dan kuantitas barang yang diterima pemasok guna menentukana dapat atau tidaknya barang tersebut diterima oleh perusahaan. Fungsi ini juga bertanggung jawab untuk menerima barang dari pembeli yang berasal dari transaksi retur penjualan. 4. Fungsi akuntansi
46 Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat utang dan fungsi pencatatan persediaan. Dalam sistem akuntansi pembelian, 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. Dalam sistem akuntansi pembelian, fungsi pencatatan persediaan bertanggung jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan.
M enurut M ulyadi (2001, hal 301-303), jaringan prosedur yang membentuk system pembelian adalah : •
Prosedur permintaan pembelian Dalam prosedur ini, fungsi gudang mengajukan permintaan pembelian dalam formulir serta peermintaan kepada fungsi pembelian
•
Prosedur permintaan penawaran harga dan pemilihan pemasok Fungsi pembelian mengirim surat permintaan penawaran harga kepada pemasok untuk memperolhe informasi mengenai harga barang dan berbagai syarat pembelian yang lain untuk memungkinkan pemilihan pemasok yang akan ditunjuk sebagai pemasok barang yang diperlukan oleh perusahaan.
•
Prosedur order pembelian Fungsi pembelian mengirim surat order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit-unit organisasi lain dalam
47 perusahaan mengenai order pembelian yang telah dikeluarkan oleh perusahaan. •
Prosedur penerimaan barang Fungsi penerimaan barang melakukan pemeriksaan mengenai jenis, kuantitas dan mutu bahan yang diterima dari pemasok dan kemudian membuat laporan penerimaan barang untuk menyatakan penerimaan barang dari pemasok tersebut.
•
Prosedur pencatatan hutang Fungsi akuntansi memeriksa dokumen-dokumen yang berhubungan dengan pembelian (SOP, laporan penerimaan barang, faktur dari pemasok) dan menyelenggarakan pencatatan ulang atau pengarsipan dokumen sumber sebagai catatan hutang.
•
Prosedur distribusi pembelian Prosedur ini meliputi distribusi rekening yang didebet dari transaksi pembelian untuk kepentingan laporan manajemen.
M enurut M ulyadi (2001, hal 335), sistem retur pembelian digunakan dalam perusahaan untuk pengembalian barang yang sudah dibeli kepada pemasoknya. Adapun barang yang sudah diterima dari pemasok terkadang tidak sesuai dengan barang yang dipesan menurut surat order pembelian. Ketidaksesuaian itu terjadi kemungkinan karena barang yang diterima tidak cocok dengan spesifikasi yang tercantum dalam surat order pembelian, barang mengalami kerusakan dalam
48 pengiriman, atau barang diterima melewati tanggal pengiriman yang dijanjikan oleh pemasok. Fungsi yang terkait dalam sistem retur pembelian adalah : 1. Fungsi Gudang Fungsi ini bertanggung jawab untuk menyerahkan barang kepada fungsi pengiriman seperti yang tercantum dalam tembusan memo debit yang diterima dari fungsi pembelian. 2. Fungsi Pembelian Fungsi ini bertanggung jawab untuk mengeluarkan memo debit untuk retur pembelian. 3. Fungsi pengiriman Fungsi ini bertanggung jawab untuk mengirimkan kembali barang kepada pemasok sesuai dengan perintah retur pembelian dalam memo debit yang diterima dari fungsi pembelian. 4. Fungsi Akuntansi Fungsi ini bertanggung jawab untuk mencatat : a. Transaksi retur pembelian dalam jurnal retur pembelian atau jurnal umum. b. Berkurangnya harga pokok persediaan karena retur pembelian dalam kartu persediaan. c. Berkurangnya utang yang timbul dari transaksi retur pembelian dalam arsip bukti kas keluar yang belum dibayar atau dalam kartu utang.
M enurut M ulyadi (2001, hal 339), sistem retur pembelian terdiri dari jaringan prosedur berikut ini :
49 1. Prosedur perintah retur pembelian Retur pembelian terjadi atas perintah fungsi pembelian kepada fungsi pengiriman untuk mengirimkan kembali barang yang telah diterima oleh fungsi penerimaan kepada pemasok yang bersangkutan. Dokumen yang digunakan oleh fungsi pembelian untuk memerintahkan fungsi pengiriman mengembalikan barang ke pemasok adalah memo debit. 2. Prosedur pengiriman barang ke pemasok Fungsi pengiriman barang kepada pemasok sesuai dengan perintah retur pembelian yang tercantum dalam memo debit dan membuat laporan pengiriman barang untuk transaksi retur pembelian tersebut. 3. Prosedur pencatatan utang Fungsi akuntansi memeriksa dokumen-dokumen yang berhubungan dengan retur pembelian dan mnyelenggarakan pencatatan berkurangnya utang dalam kartu utang atau mengarsipkan dokumen memo debit sebagai pengurang utang.
2.2.2 Persediaan 2.2.2.1 Definisi Persediaan M enurut M ulyadi ( 2001, hal 553 ), dalam perusahaan dagang, persediaan hanya terdiri dari persediaan barang dagangan, yang merupakan barang yang dibeli untuk dijual kembali.
50 2.2.2.2 Jenis – jenis Persediaan M enurut Thomas R. Dyckman (2001, hal 378), persediaan terdiri dari barang-barang yang dimiliki suatu bisnis dan disimpan baik untuk digunakan membuat produk atau sebagai produk yang siap untuk dijual dan dapat diklasifikasikan sebagai berikut : 1. Persediaan barang dagang (merchandise inventory) Barang yang ada di gudang dibeli oleh pengecer atau perusahaan perdagangan seperti importer atau eksportir untuk dijual kembali.. Biasanya, barang yang diperoleh untuk dijual kembali secara fisik tidak diubah oleh perusahaan pembeli. 2. Persediaan manufaktur Persediaan dari entitas manufaktur, yang terdiri dari: •
Persediaan bahan baku Barang yang berwujud dibeli atau diperoleh dengan cara lain (misal, dengan menambang) dan disimpan untuk penggunaan langsung dalam membuat barang untuk dijual kembali.
•
Persediaan barang dalam proses Barang-barang yang membutuhkan pemrosesan lebih lanjut sebelum penyelesaian dan penjualan.
•
Persediaan barang jadi Barang-barang manufaktur yang telah diselesaikan dan disimpan untuk dijual.
•
Persediaan cadangan manufaktur
51 Antara lain : minyak pelumas untuk mesin, bahan pembersih dan bahan lainnya. 3. Persediaan rupa-rupa Barang-barang seperti
perlengkapan
kantor,
kebersihan,
dan
pengiriman. Persediaan jenis ini biasanya digunakan segera dan biasanya dicatat sebagai beban penjualan atau umum ketika dibeli.
2.2.3 Penjualan M enurut M ulyadi, penjualan barang dan jasa perusahaan dapat dilaksanakan melalui penjualan tunai atau penjualan kredit. 1. Penjualan Kredit (M ulyadi, 2001, hal 202) Dalam transaksi penjualan kredit, jika pesanan dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Kegiatan penjualan kredit ini ditangani oleh perusahaan melalui sistem penjualan kredit. Sistem penjualan kredit dilaksanakan oleh perusahaan dengan cara mengirimkan barang sesuai pesanan yang diterima dari pembeli dan untuk jangka waktu tertentu perusahaan mempunyai tagihan kepada pembeli tersebut. 2. Penjualan tunai (M ulyadi, 2001, hal 455-459 ) Penjualan
tunai
dilaksanakan
oleh
perusahaan
dengan
cara
mewajibkan pembeli melakukan pembayaran harga barang terlebih dahulu sebelum barang diserahkan kepada pembeli. Setelah uang diterima oleh
52 perusahaan, barang kemudian diserahkan kepada pembeli dan transaksi penjualan tunai kemudian dicatat oleh perusahaan. Fungsi yang terkait dengan sistem penjualan adalah sebagai berikut : 1. Fungsi Penjualan Bertanggung jawab menerima surat pesanan dari pelanggan, mengedit informasi-informasi yang belum lengkap pada surat pesanan tersebut dan meminta otorisasi kredit. 2. Fungsi Kredit Bertanggung jawab dalam meneliti status kredit pelanggan dan memberikan otorisasi pemberian kredit pada pelanggan. 3. Fungsi Gudang Bertanggung jawab untuk menyimpan dan menyediakan barang yang dipesan oleh pelanggan dan mengirim barang ke bagian pengiriman beserta surat julan. 4. Fungsi Pengiriman Bertanggung jawab membuat dan mengirimkan faktur penjualan kepada pelanggan
serta
menyediakan
tembusan
faktur
bagi
kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi. 5. Fungsi penagihan Bertanggung jawab untuk membuat dan mengirimkan faktur penjualan kepada pelanggan, serta menyediakan salinan faktur bagi kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi. 6. Fungsi Akuntansi
53 Bertanggung jawab untuk mencatat piutang yang timbul dari transaksi penjualan kredit dan mengirimkan pernyataan piutang kepada debitur, serta membuat laporan penjualan. Di samping itu, fungsi ini juga bertanggung jawab untuk mencatat harga pokok persediaan yang dijual ke dalam kartu persediaan.
M enurut M ulyadi (2000, hal 219) sistem dan prosedur yang bersangkutan dengan sistem penjualan kredit adalah: a. Prosedur Order Penjualan Dalam prosedur ini fungsi penjualan menerima pesanan dari pembeli dan menambahkan informasi penting pada surat order dari pembeli. Fungsi penjualan kemudian membuat surat order pengiriman dan mengirimkannya kepada berbagai fungsi yang lain untuk memungkinkan fungsi tersebut memberikan kontribusi dalam melayani order dari pembeli. b. Prosedur Persetujuan Kredit Dalam prosedur ini, fungsi penjualan meminta persetujuan penjualan kredit kepada pembeli tertentu dari fungsi kredit. c. Prosedur Pengiriman Dalam prosedur ini, fungsi pengiriman mengirimkan barang kepada pembeli sesuai dengan informasi yang tercantum dalam surat order pengiriman yang diterima dari fungsi pengiriman. d. Prosedur Penagihan Dalam prosedur ini, fungsi penagihan membuat faktur penjualan dan mengirimkannya kepada pembeli. Dalam metode tertentu faktur penjualan
54 dibuat oleh fungsi penjualan sebagai tembusan pada waktu bagian ini membuat surat order pengiriman. e. Prosedur pencatatan Piutang Dalam prosedur ini, fungsi akuntansi mencatat tembusan faktur penjualan ke dalam kartu piutang atau dalam metode pencatatan tertentu mengarsipkan dokumen tembusan menurut abjad yang berfungsi sebagai catatan piutang. f. Prosedur Distribusi Penjualan Dalam prosedur ini, fungsi akuntansi mendistribusikan data penjualan menurut informasi yang diperlukan oleh manajemen. g. Prosedur Pencatatan Harga Pokok Penjualan Dalam prosedur ini, fungsi akuntansi mencatat secara periodik total harga pokok produk yang dijual dalam periode akuntansi tertentu.
M enurut M ulyadi (2001, hal 226), transaksi retur penjualan terjadi jika perusahaan menerima pengembalian barang dari pelanggan. Pengembalian barang oleh pelanggan harus diotorisasi oleh fungsi penjualan dan diterima oleh fungsi penerimaan. Fungsi yang terkait dalam melaksanakan transaksi retur penjualan adalah : 1. Fungsi penjualan Fungsi ini bertanggung jawab atas penerimaan pemberitahuan mengenai pengembalian barang yang telah dibeli oleh pembeli. Otorisasi penerimaan kembali barang yang telah dijual tersebut dilakukan dengan cara membuat memo kredit yang dikirimkan kepada fungsi penerimaan. 2. Fungsi penerimaan
55 Fungsi ini bertanggung jawab atas penerimaan barang berdasarkan otorisasi yang terdapat dalam memo kredit yang diterima dari fungsi penjualan. 3. Fungsi gudang Fungsi ini bertanggung jawab atas penyimpanan kembali barang yang diterima dari retur penjualan setelah barang tersebut diperiksa oleh fungsi penerimaan. Barang yang diterima dari transaksi retur penjualan ini dicatat oleh fungsi gudang dalam kartu gudang. 4. Fungsi akuntansi Fungsi ini bertanggung jawab atas pencatatan transaksi retur penjualan ke dalam
jurnal umum
dan
pencatatan
berkurangnya piutang dan
bertambahnya persediaan akibat retur penjualan dalam kartu piutang dan kartu persediaan. Di samping itu, fungsi ini juga bertanggung jawab untuk mengirimkan memo kredit kepada pembeli yang bersangkutan.
M enurut M ulyadi (2001, hal 234), jaringan prosedur dalam sistem retur penjualan adalah sebagai berikut : 1. Prosedur pembuatan memo kredit Fungsi penjualan membuat memo kredit yang memberikan perintah kepada fungsi penerimaan untuk menerima barang dari pembeli tersebut dan kepada fungsi akuntansi untuk pencatatan pengurangan piutang kepada pembeli yang bersangkutan. 2. Prosedur penerimaan barang
56 Fungsi penerimaan menerima dari pembeli berdasarkan perintah dari memo kredit yang diterima dari fungsi penjualan. Atas penerimaan barang tersebut fungsi penerimaan membuat laporan penerimaan barang untuk melampiri memo kredit yang dikirim ke fungsi akuntansi. 3. Prosedur pencatatan retur penjualan Dalam prosedur ini transaksi berkurangnya piutang dagang dan pendapatan penjualan akibat dari transaksi retur penjualan dicatat oleh fungsi akuntansi ke dalam jurnal umum atau jurnal retur penjualan dan ke dalam buku pembantu piutang. Dalam prosedur ini pula berkurangnya harga pokok penjualan dan bertambahnya harga pokok persediaan dicatat oleh fungsi akuntansi ke dalam jurnal umum dan dalam buku pembantu persediaan.
