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.
2.1.2 Database Lifecycle
Gambar 2.1 Database Life Cycle
Databas e planning
System definition
Requirements colection and analy sis
Database design Conceptual database design Logical database design P hysical database design P rototyping ( optional ) Implementation Data conversion and loading Testing Operational maintenance DBMS selection Application design
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.
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 ).
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 ukuran-ukuran keamanan.
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
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.
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.
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.
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
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
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
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 key-nya.
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 non-primary key attribute is transitively dependent on the non-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
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
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.
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).
1.6 M empertimbangkan penggunaan konsep enhanced modeling
Bertujuan untuk mempertimbangkan konsep enhanced
modeling seperti spesialisasi atau generalisasi, 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 generalisasi, diusahakan untuk mengidentifikasikan fitur-fitur umum 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
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.
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.
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:*)
- 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 integritas yang direpresentasikan ke dalam model data logikal.
Ada 5 tipe batasan integritas yaitu : 1. Data yang dibutuhkan
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 key-nya. 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.
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
dikembangkan berdasarkan langkah 2.6) yang digunakan untuk mendukung perkembangan di masa akan datang.
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
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.
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 dapat meningkatkan permintaan pada sistem basis data.
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:
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.
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.
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
one-to-many (1:*) untuk mengurangi join.
3. M enduplikasi atribut-atribut foreign key di dalam relasi one-to-many (1:*)
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.
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
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
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
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
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.
• 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 :
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.
State X
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
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
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
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 :
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.
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.
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
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
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
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.
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.
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.
