7
BAB 2
LANDASAN TEORI
2.1 Pendekatan Basisdata
2.1.1 Pengertian Sistem
Menurut Mulyadi (2001, p2) suatu sistem pada dasarnya adalah
sekelompok unsur yang erat hubungannya antara satu dengan lainnya, yang
berfungsi bersama-sama untuk mencapai suatu tujuan tertentu. Rincian dari
definisi sistem adalah setiap sistem teridiri dari unsur-unsur, unsur-unsur
tersebut merupakan bagian terpadu sistem yang bersangkutan, unsur sistem
tersebut bekerja sama untuk mencapai tujuan sistem dan suatu sistem
merupakan bagian dari sistem lain yang lebih besar.
Menurut Romney dan Steinbart (2003, p2) “A system is a set of two or
more interrelated components that interact to achieve a goal.” yang berarti
bahwa sebuah sistem adalah suatu set dari dua atau lebih komponen-
komponen terelasi yang saling mendukung untuk mencapi satu tujuan.
2.1.2 Pengertian Sistem Informasi
Menurut James A O’Brien (2003, p5) sistem informasi adalah kombinasi
teratur apapun dari orang-orang, hardware, software jaringan komunikasi,
dan sumber daya data yang mengumpulkan, mengubah, dan menyebarkan
informasi dalam sebuah organisasi.
Menurut Kenneth C. Laudon dan Jane P. Laudon (2003, p7) “Infomation
system can be defined technically as a set of interrelated components
8
that collect (or retrieve), process, store, and distribute information to
support decision making, coordination, and control in an organization.”
yang berarti bahwa sistem informasi adalah tehnik dari satu set interleasi
komponen-komponen yang melakukan kegiatan mengumpulkan (atau
menerima), melakukan, menyimpan, dan membagikan informasi untuk
mendukung pengambilan keputusan, koordinasi dan kontrol pada sebuah
organisasi.
2.1.3 Pengertian Sistem Berbasis File
Aplikasi database pada saat ini telah banyak digunakan dan merupakan hal
umum dalam kegiatan sehari-hari. Contoh program database yaitu data-data
mahasiswa dalam suatu universitas, pembelian barang dalam suatu
perusahaan tertentu, buku-buku diperpustakaan dan sebagainya. Tetapi
sebelum ada aplikasi database seperti DBMS, penyimpanan data
mengunakan penyimpanan dalam suatu file.
Menurut Connolly (2002, p7) file-based system is ”A collection of
application programs that performs services for the end-users such as the
production of reports. Each programs defines and manages each own
data.” yang artinya suatu kumpulan dari program aplikasi yang
memberikan pelayanan kepada pengguna aplikasi seperti pembuatan suatu
laporan. Setiap program mendefinisikan dan mengatur datanya masing-
masing. Tetapi muncul permasalahan yaitu banyak keterbatasan dari
pendekatan menggunakan file, antara lain:
Data yang terduplikasi
9
Data yang terisolasi dan terpisah
Ketergantungan data
Format file yang tidak kompatible
Query yang tetap atau tidak dapat mengatisipasi perkembangan
program aplikasi.
Kemudian muncul pendekatan dengan menggunakan database dan database
management system (DBMS).
2.1.4 Pengertian Basisdata
Menurut Connolly (2002, p14) Database is “A shared collection of
logically related data, and a description of this data, designed to meet the
information needs of an organization.” yang berarti basisdata adalah
kumpulan data yang terbagi dan terhubung secara logikal dan deskripsi dari
data yang dirancang untuk memenuhi kebutuhan informasi suatu
organisasi.
Menurut Elmasri, Navathe (2000, p4) “A database is a collection of related
data.” yang berarti bahwa sebuah basisdata adalah sebuah kumpulan dari
data yang terrelasi.
Menurut C. J. Date (2000, p9) “A database consist of some collection of
persistents data that is used by the application system of given enterprise.”
Yang berarti bahwa database terdiri dari beberapa kumpulan dari data tetap
yang digunakan oleh sistem aplikasi untuk diberikan kepada perusahaan.
10
2.1.5 Database Management Sistem (DBMS)
Menurut Connolly (2002, p16) Database management Sistem (DBMS) is
“As a software system able to manage collection of data that are large,
shared and persistent and to ensure their reliabilty and privacy.” yang
berarti DBMS adalah suatu sistem perangkat lunak yang memungkinkan
pengguna untuk mendefinisikan, membuat, memelihara, dan mengontrol
akses ke basisdata.
Menurut Elmasri, Navathe (2000, p5) “DBMS is a collection of programs
that enables users to create and maintain a database.” yang berarti bahwa
DBMS adalah sebuah kumpulan program yang dugunakan oleh user-user
untuk membuat dan merawat sebuah database.
Menurut Silberschatz, Korth, dan Sudarshan (2002, p1) “DBMS is a
collection of interrelated data and a set of programs to access those data.”
yang berarti bahwa DBMS adalah sebuah kumpulan dari data interelasi dan
satu set kumpulan dari program-program untuk mengakses data-data itu.
Kembali menurut Connolly, biasanya DBMS memiliki fasilitas-fasilitas
sebagai berikut:
Fasilitas untuk mendefinisikan database, biasanya mengunakan
sebuah Data Definition Language (DDL). DDL mengizinkan
pengguna untuk menspesifikasikan tipe, struktur dan batasan aturan
mengenai data yang bisa disimpan ke dalam basisdata tersebut.
Fasilitas untuk mengizinkan pengguna menambah, mengedit,
menghapus, dan mendapatkan kembali data dari database, biasanya
mengunakan Data Manipulation Language (DML). Ada pula suatu
11
fasilitas yang melanyani pengaksesan data yang disebut query
language. Bahasa yang diakui adalah Structured Query Language
(SQL), yang merupakan standart bagi DBMS.
Fasilitas untuk mengkontrol ke basisdata (DCL). Contoh:
o Suatu sistem keamanan yang mencegah user yang tidak
punya autoritas untuk mengakses data.
o Suatu sistem terintegrasi yang memelihara konsistensi
penyimpanan data.
o Suatu sistem kontrol yang mengizinkan akses ke basisdata.
o Suatu sistem kontrol pengembalian data yang mana dapat
mengembalikan data ke keadaan sebelumnya apabila terjadi
kegagalan perangkat keras atau perangkat lunak.
o Terdapat suatu katalog yang dapat diakses oleh pengguna,
yang menjelaskan data di dalam basisdata tersebut.
Keunggulan DBMS adalah:
Kontrol terhadap redundansi data.
Data yang konsisten.
Semakin banyak informasi yang didapat dari data yang sama.
Data yang dibagikan (shared data).
Menambah integritas data.
Menambah keamanan data.
Penetapan standarisasi.
Menyeimbangkan konflik kebutuhan.
Memperbaiki pengaksesan data dan hasilnya.
12
Menambah produktivitas.
Memperbaiki pemeliharaan data melalui data independence.
Meningkatkan concurrency.
Kelemahan DBMS adalah:
Kompleksitas.
Ukuran size.
Biaya suatu DBMS.
Biaya penambahan perangkat keras.
2.1.6 Data Definition Language (DDL)
Pengertian dari Data Definition Language menurut Connolly (2002, p40)
Data Definition Language is “a language that allows the DBA or user to
described and name the entities, attributes and relationships required for
the application, together with any associated integrity and security
constraints” yang memiliki arti suatu bahasa yang mengizinkan Database
Administrator (DBA) atau pengguna untuk menjelaskan dan memberi nama
suatu entitas, atribut, dan relasi data yang dibutuhkan untuk aplikasi,
bersama dengan beberapa integritas data yang diasosiasikan dan batasan
keamanan data.
Menurut Silberschatz, Korth, dan Sudarshan (2002, p11) “We specify a
database schema by a set of definitions expressed by a special language
called a data-definition language (DDL).” yang memiliki arti ketika kita
menetapkan skema database dengan satu set definisi yang dinyatakan
dengan bahasa khusus maka disebut data definition language (DDL).
13
Contoh:
create tabel account
(account_number char (10),
balance integer)
2.1.7 Data Manipulation Language (DML)
Pengertian dari Data Manipulation Language menurut Connolly (2002,
p41) Data Manipulation Language is “A language that provides a set of
operations to support the basic data manipulation operations on the data
held in the database” yang memiliki arti suatu bahasa yang menyediakan
seperangkat operasi untuk mendukung manipulasi data yang berada pada
basisdata.
Pengoperasian data yang akan dimanipulasi biasanya meliputi :
Penambahan data baru ke dalam basisdata
Modifikasi data yang disimpan ke dalam basisdata
Pengembalian data yang terdapat di dalam basisdata.
Penghapusan data dari basisdata.
Sedangkan pengertian dari Procedural DML menurut Connolly (2002, p41)
Procedural DML is “A language that allows the user to tell the system,
what data is needed and exactly how to retrieve the data” yang memiliki
arti bahwa suatu bahasa yang mengizinkan pengguna untuk
mendeskripsikan ke sistem data apa yang dibutuhkan dan bagaimana
mendapatkan data tersebut secara tepat.
14
Menurut Silberschatz, Korth, dan Sudarshan (2002, p11) “A data-
manipulation language (DML) is a language that enables users to access or
manipulate data as organized by the appropriate data model.” yang
memiliki arti bahwa data-manipulation language (DML) adalah sebuah
bahasa yang memampukan user-user untuk mengkases atau memanipulasi
data seperti yang diorganisasikan oleh data model yang tepat.
Contoh:
select customer_name
from customer
where id_customer=1132
2.1.8 Siklus Hidup Aplikasi Basisdata
Pengertian dari siklus hidup aplikasi basisdata menurut Connolly (2002,
p271) the database application lifecycle is “As a database system is a
fundamental component of the larger organization-wide information
system” yang memiliki arti sistem basisdata merupakan suatu komponen
dasar dari organisasi dengan sistem informasi yang besar.
Hal ini sangat penting untuk diperhatikan karena struktur dari siklus hidup
aplikasi basisdata tidaklah harus benar-benar sekuensial, tetapi meliputi
suatu perulangan dari bagan-bagan yang sebelumnya melalui umpan balik.
Sebagai contoh, masalah yang dihadapi selama perancangan basisdata
adalah masih diperlukannya analisis dan pengumpulan data tambahan.
Untuk aplikasi basisdata kecil dengan jumlah pengguna yang sedikit, siklus
hidup tidak terlalu kompleks. Bagaimanapun juga, ketika perancangan
15
sedang dilakukan pada suatu aplikasi basisdata ukuran sedang dengan
jumlah pengguna antara sepuluh sampai dengan ribuan pengguna, dengan
menggunakan ratusan queries dan program aplikasi, siklus hidup akan
menjadi kompleks.
Bagan siklus hidup aplikasi basisdata:
16
Gambar 2.1 Siklus Hidup Aplikasi Basisdata
(Connolly 2002, p272)
17
Berikut ini adalah penjelasan singkat tentang apa kegiatan utama dari setiap
langkah siklus hidup aplikasi basisdata menurut Connolly:
Database Planning
Merencanakan bagaimana tahapan dari siklus hidup bisa direalisasikan
secara efektif dan efisien. Database planning harus diintegrasikan dengan
sistem informasi perusahaan secara keseluruhan. Ada tiga persoalan dalam
merumuskan strategi sistem informasi:
Mendefinisikan rencana dan tujuan perusahaan dengan
mempertimbangkan kebutuhan sistem informasi berikutnya.
Mengevaluasi sistem informasi yang ada untuk memberi
pertimbangan atas kekuatan dan kelemahannya.
Penilainan dari teknologi informasi yang mungkin menghasilkan
keuntungan berarti.
System Definition
Sebelum menerapkan untuk mendesain sebuah aplikasi basisdata, perlu kita
mendefinisikan dahulu batas-batas dari sistem yang akan kita teliti dan
bagaimana sistem ini berhadapan dengan bagian-bagian yang lain dalam
sistem informasi perusahaan. Jadi pada langkah definisi sistem dilakukan
penjelasan ruang lingkup dan batasan dari aplikasi sistem basisdata,
penggunanya, dan cakupan aplikasi tersebut.
Requirements Collection and Analysis
Dalam langkah ini terjadi proses mengumpulkan dan menganalisis
informasi tentang bagian dari organisasi yang didukung oleh aplikasi
18
basisdata, dan menggunakan informasi ini untuk mendefinisikan kebutuhan
atau permintaan user-user dalam sistem yang baru.
Database Design
Dalam tahap ini terjadi proses pembuatan sebuah basisdata yang akan
mendukung operasi dan tujuan dari perusahaan. Meliputi rancangan
konseptual, logikal, dan fisikal dari basisdata.
Desain basisdata konseptual adalah proses membangun sebuah
model dari informasi yang digunakan dalam perusahaan, bebas dari
semua pertimbangan fisikal.
Desain basisdata logikal adalah proses membangun sebuah model
dari informasi yang digunakan dalam sebuah dasar perusahaan pada
sebuah data model yang khusus, tetapi bebas dari fakta DBMS dan
pertimbangan fisikal
Desain basisdata fisikal adalah proses menghasilkan sebuah
penjelasan dari implementasi pada basisdata di secondary storage,
termasuk menentukan relasi dasar, catatan atau arsip organisasi, dan
index yang digunakan untuk mencapai akses data yang efisien dan
beberapa penyesuaian keutuhan yang mendesak dan tingkat
keamanan.
DBMS Selection (optional)
Memilih suatu DBMS yang cocok untuk aplikasi sistem basisdata.
Meskipun pemilihan DBMS jarang terjadi, tetapi perusahaan butuh
memperluas atau membuat sistem yang akan diganti, hal ini mungkin
19
menjadi suatu yang diperlukan pada saat menilai atau mengevaluasi DBMS
yang baru.
Application Design
Merancang antarmuka pemakai dan program aplikasi yang menggunakan
dan memproses sistem basisdata. Kita harus dapat memastikan semua
fungsi dalam tiap bagian pada kebutuhan khusus user-user telah ada dalam
desain aplikasi untuk aplikasi basisdata.
Prototyping (optional)
Membangun suatu model kerja dari aplikasi basisdata, yang mana
mengizinkan perancang atau pengguna untuk memvisualisasikan dan
mengevaluasi bagaimana gambaran sistem secara keseluruhan dan
fungsinya.
Ada dua strategi prototyping yaitu requirements prototyping and
evolutionary prototyping.
requirements prototyping adalah prototype (bentuk dasar) untuk
menimbang kebutuhan dari maksud aplikasi basisdata dan
kebutuhan keseluruhan prototype (bentuk dasar) dibuang.
Evolutionary prototyping digunakan untuk tujuan yang sama,
perbedaan yang pentung adaah prototype (bentuk dasar) tidak
dibuang tetapi dengan penemuan lebih dalam menjadi pekerjaan
aplikasi basisdata.
Implementation
Dalam tahap ini kita mengunakan Data Definition Language (DDL) dari
pemilihan DBMS atau sebuah graphical user interface (GUI), yang
20
menyediakan fungsi sama ketika menyembunyikan low-level pernyataan
DDL. DDL statement (pernyataan DDL) digunakaan untuk membuat
truktur basisdata dan file basisdata yang kosong. Dari user view, security
(keamanan) dan kontrol integritas untuk aplikasi juga diimplementasikan
pada tahap ini. Dapat disimpulkan bahwa tahap implementasi adalah
membuat definisi basisdata eksternal, konseptual, dan internal dan program
aplikasinya.
Data Conversion and Loading
Memindahkan semua data yang ada kedalam suatu basisdata yang baru dan
mengubah semua aplikasi yang ada untuk dapat berjalan pada basisdata
yang baru. Tahap ini terjadi jika ketika sistem basisdata yang baru
menggantikan sistem basisdata yang lama.
Testing
Proses menjalankan program aplikasi dengan bertujuan menemukan
kesalahan. Sebelum program digunakan, kita harus melakukan tes. Untuk
mencapai tes yang sempurna, digunakan strategi tes yang direncanakan dan
mengunakan data asli jadi segala proses-proses tes memiliki metode dan
ketelitian.
Operational Maintenance
Setelah aplikasi basisdata diimplementasikan, tentunya sistem ini akan
terus diawasi (dimonitor) dan dipelihara.
Mengawasi (memonitor) dayaguna (performance) sistem. Jika
dayaguna berkurang dibawah yang level yang sudah ditetapkan,
maka perlu dilakukan mereorganisasi basisdata.
21
Merawat dan mengubah (menambahkan) aplikasi basisdata pada
saat dibutuhkan. Apabila ada kebutuhan baru maka harus
dimasukkan kedalam aplikasi basisdata melalui tahapan-tahapan
proses yang ada dalam siklus hidup.
2.1.9 Tahap-tahap Basisdata
Didalam perancangan basisdata terdiri dari tiga bagian penting yaitu
perancangan basisdata konseptual, logikal, dan fisikal.
Perancangan Konseptual
Pengertian perancangan konseptual basisdata menurut Connolly (2002,
p419) “The process of constructing a model of the information used in an
enterprise, independent of all physical considerations.” Yang berarti proses
pembuatan suatu model dari informasi yang digunakan dalam suatu
organisasi, yang tidak tergantung pada segala pertimbangan fisikal. Pada
tahap perancangan konseptual terdapat satu langkah besar yaitu
membangun model data lokal konseptual untuk setiap view (langkah 1).
Langkah 1 membangun model data lokal konseptual untuk setiap
view
Langkah 1 terdiri dari:
1. Identifikasi Tipe Entitas
Tujuan dari langkah ini adalah untuk mengidentifikasi entitas utama
yang dibutuhkan oleh view.
Langkah pertama dalam membangun suatu model data lokal konseptual
adalah untuk mendefinisikan objek utama di mana user memang
22
membutuhkannya. Salah satu metode untuk mengidentifikasi tipe
entitas yang utama adalah dengan mengidentifikasi kata benda atau
frase kata benda yang telah disebutkan oleh user.
2. Identifikasi Tipe Relasi
Tujuan dari langkah ini adalah untuk mengidentifikasi relasi yang
penting antara berbagai tipe entitas yang telah diidentifikasikan.
Biasanya, relasi diidentifikasi dengan menggunakan kata kerja atau
frase kata kerja.
Adapun langkah-langkah dalam mengidentifikasi tipe relasi adalah
sebagai berikut :
• Gunakan Entiti-Relationship (ER) diagrams
Hal yang sering terjadi adalah pengguna akan lebih cepat mengerti
suatu perancangan basisdata dengan cara divisualisasikan
dibandingkan dengan perancangan basisdata yang dituliskan dalam
bentuk teks. Entiti Relationship (ER) diagrams digunakan untuk
merepresentasikan entitas dan bagaimana relasi antar entitas.
Disarankan menggunakan Entiti Relationship (ER) diagrams untuk
membantu dalam membuat gambaran besar dari perusahaan yang
sedang dikembangkan perancangan basisdata-nya.
• Tentukan Multiplicity constraints dari tipe relasi
Setelah terdapat relasi antara entitas, maka langkah berikutnya
adalah menentukan multiplicity setiap relasi. Jika memang ada suatu
nilai yang spesifik dari suatu multiplicity maka akan lebih baik
23
apabila didokumentasikan. Multiplicity constraints digunakan untuk
mengecek dan menjaga kualitas data.
• Mengecek Fan dan Chasm Traps
Setelah didefinisikan relasi yang dibutuhkan antar entitas, maka
langkah berikutnya adalah mengecek fan dan chasm traps. Definisi
dari fan traps adalah suatu model yang merepresentasikan suatu
relasi antara entitas, tetapi alur relasinya memperlihatkan
ambiguitas. Definisi dari chasm traps adalah suatu model di mana
ada hubungan antara entitas yang satu dengan yang lain, tetapi tidak
ada alur relasi antara kedua entitas tersebut.
• Mengecek setiap entiti mempunyai relasi minimal satu.
Pada saat pembuatan Entiti Relationship (ER) diagrams, pastikan
setiap entitas mempunyai minimal satu relasi dengan entitas lain.
Jika memang ada entitas yang sudah mempunyai minimal satu
relasi dengan entitas lain, maka langkah berikutnya adalah
perhatikan kamus datanya.
3. Identifikasi dan mengasosiasikan atribut dengan entitas atau tipe
relasi
Tujuan dari langkah ini adalah untuk mengasosiasikan atribut dengan
entitas atau tipe relasi yang sesuai.
Berikut ini adalah macam-macam atribut:
Simple/Composite Attributes
Perlu diperhatikan apakah suatu atribut tersebut itu simple atau
composite. Composite Attribute adalah atribut yang terdiri dari
24
beberapa simple attribute. Sebagai contoh, atribut alamat bisa saja
dibuat simple dan menyimpan beberapa detil dari alamat sebagai suatu
nilai.
Single/Multy-valued Attributes
Suatu atribut dapat mengandung single atau multi-valued. Contoh
atribut yang mengandung multiple value: nomor telepon dari entitas
client.
Derived Attributes
Atribut yang nilainya tergantung dengan nilai atribut yang lain, maka
atribut ini disebut sebagai Derived Atribut. Sebagai contoh : umur dari
seorang staf., jumlah property yang dikelola oleh seorang staf.
4. Menentukan domain atribut
Tujuan dari langkah ini adalah untuk menentukan domain dari atribut
yang ada di dalam model data lokal konseptual. Menurut Connolly
(2002, p338) Attribute Domain is “the set of allowable values for one
or more attributes.” Yang memiliki arti bahwa domain atribut adalah
himpunan nilai yang diperbolehkan untuk satu atau lebih atribut.
Sebagai contoh : Atribut dari NoStaf terdiri dari enam karakter tipe
string di mana dua karakter utama merupakan huruf, sedangkan empat
karakter sisa berupa angka.
5. Menentukan atribut candidate dan primary key
Tujuan dari langkah ini adalah untuk mengidentifikasi candidate key
dari setiap tipe entitas, dan jika memang terdapat lebih dari satu
candidate key, pilih salah satunya untuk menjadi primary key.
25
Pada saat pemilihan suatu primary key di antara banyak candidate key,
gunakan petunjuk berikut ini untuk membantu menyeleksi:
• Merupakan candidate key dengan jumlah set paling sedikit
• Merupakan candidate key yang nilainya jarang sekali berubah
• Merupakan candidate key dengan jumlah karakter paling sedikit
• Merupakan candidate key dengan jumlah paling sedikit dari nilai
maksimumnya (untuk tipe atribut dengan tipe numerik)
• Merupakan candidate key yang paling mudah digunakan dari sudut
pandang pengguna.
6. Mempertimbangkan penggunaan enhanced modeling concepts
(langkah optional)
Tujuan dari langkah ini adalah untuk mempertimbangkan penggunaan
enhanced modeling concepts, seperti specialization, generalization,
aggregation, dan composition.
Jika anda menggunakan pendekatan specialization, maka perhatikan
perbedaan antara entitas dengan mendefinisikan satu atau banyak
subclasses dari entitas superclass. Sedangkan jika menggunakan
pendekatan generalization, maka anda akan mengidentifikasi fitur-fitur
yang umum antara entitas untuk membentuk entitas superclass.
7. Mengecek Redudansi
Tujuan dari langkah ini adalah untuk mengecek apakah ada redundansi
dalam model basisdata.
26
Pada langkah ini, dilakukan pengujian lokal konseptual data dengan
penglihatan secara spesifik, apabila ada redundansi maka dapat
dihilangkan redundansi tersebut dengan dua langkah berikut:
• Menguji kembali hubungan one-to-one
• Menghilangkan relasi redundansi.
8. Validasi lokal konseptual model terhadap transaksi user
Tujuan dari langkah ini adalah untuk memastikan bahwa lokal
konesptual model mendukung permintaan transaksi oleh view.
Pengujian dilakukan dengan dua kemungkinan pendekatan dengan
memastikan bahwa Model Data Konseptual Lokal mendukung
permintaan transaksi:
• Deskripsikan transaksi.
• Gunakan alur transaksi.
9. Me-review model data lokal konseptual dengan user
Tujuan dari langkah ini adalah untuk mengkaji ulang model data lokal
konseptual bersama user untuk memastikan bahwa model yang ada
sudah sesuai dengan yang diminta.
Hasil akhir dari perancangan konseptual basisdata adalah memproses
pembuatan suatu model dari informasi yang akan digunakan dalam
suatu organisasi, yang tidak tergantung pada segala pertimbangan
fisikal.
27
Perancangan Basisdata Logikal
Adapun pengertian dari perancangan basisdata logikal menurut Connolly
(2002, p281) “The process of constructing a model of the information used
in an enterprise based on a specific data model, but independent of
particular DBMS and other physical considerations.” Yang artinya proses
pembuatan suatu model dari informasi yang digunakan di dalam suatu
organisasi berdasarkan model data yang spesifik, tapi tidak tergantung pada
suatu DBMS dan perangkat keras lainnya. Pada tahap perancangan
basisdata logikal terdiri dari dua langkah besar yaitu Membuat dan
memvalidasi model data lokal logikal untuk setiap bagian (langkah 2) dan
Membangun dan memvalidasi model data logikal global (langkah 3).
Langkah 2 Membuat dan memvalidasi model data lokal logikal untuk
setiap bagian
Pada langkah ini bertujuan untuk membangun suatu model data lokal
logikal dari suatu model data lokal konseptual yang merepresentasikan
perusahaan dan kemudian memvalidasi model ini untuk memastikan
strukturnya benar, dan memastikan bahwa model tersebut mendukung
transaksi yang diminta.
Relationship yang paling umum adalah binary relationship.
Macam-macam binary relationship yaitu :
• one-to-one (1:1)
• one-to-many (1 : *)
• many-to-many (* : *)
28
Langkah 2 Terdiri dari:
1. Menghilangkan bagian yang tidak sesuai dengan model relasi
(langkah optional)
Tujuan dari langkah ini adalah untuk memperbaiki model data lokal
konseptual dengan menghilangkan fitur yang tidak kompatibel dengan
model relasi.
Bagian yang akan dibahas pada langkah ini antara lain:
Menghilangkan many-to-many (*:*) tipe relasi binary
Menghilangkan many-to-many (*:*) tipe relasi rekursif
Menghilangkan tipe relasi kompleks
Menghilangkan multi-valued.
2. Menurunkan relasi untuk model data lokal logikal
Tujuan dari langkah ini adalah untuk membuat suatu relasi untuk model
data lokal logikal yang merepresentasikan suatu entitas, relasinya, dan
juga atribut yang telah diidentifikasi. Adapun pendeskripsian
bagaimana relasi dapat diturunkan dari struktur data model yang ada,
antara lain:
Tipe entitas kuat
Tipe entitas lemah
One-to-many (1:*) tipe relasi binary
One-to-one (1:1) tipe relasi binary
One-to-one (1:1) relasi rekursif
Superclass / subclass tipe relasi
Many-to-many tipe relasi binary
29
Tipe Relasi kompleks
Atribut multi-valued.
3. Memvalidasi relasi dengan normalisasi
Tujuan dari langkah ini adalah untuk memvalidasi relasi dalam model
data lokal logikal dengan menggunakan teknik dari normalisasi.
4. Memvalidasi relasi dengan transaksi user
Tujuan dari langkah ini adalah untuk memastikan bahwa relasi di dalam
model data lokal logikal mendukung transaksi yang diminta oleh view.
Pada langkah ini, pengecekan bahwa relasi yang dibuat di langkah
sebelumnya juga mendukung transaksi ini, dan juga pastikan bahwa
tidak ada error dalam relasi yang telah dibuat.
5. Mendefinisikan batasan-batasan integritas
Tujuan dari langkah ini adalah untuk mendefinisikan batasan-batasan
integritas yang ada pada view. Dalam hal ini ada 5 tipe dari batasan-
batasan integritas, antara lain:
• Data yang diminta
• Domain pembatas atribut
• Integritas entitas
Yang mendefinisikan suatu entitas mempunyai integritas ialah tidak
adanya primary key yang kosong (null). Suatu primary key
merupakan suatu atribut yang mendefinisikan bahwa setiap record /
tuple itu unik satu sama lain.
• Integritas referensi
30
Jika terdapat suatu foreign key dalam suatu relasi, maka nilainya
harus sesuai dengan nilai candidate key pada salah satu record di
mana foreign key tersebut berada atau foreign key tersebut
sepenuhnya kosong (null).
• Pembatas enterprise
Merupakan aturan tambahan yang dibuat oleh user atau seorang
database administrator dari basisdata tersebut.
6. Me-review model data lokal logikal dengan user
Tujuan dari langkah ini adalah untuk memastikan bahwa model data
lokal logikal dan membuat dokumentasi yang mendeskripsikan model
tersebut sebagai representasi yang sesuai dengan keadaan sebenarnya.
Langkah 3 Membangun dan memvalidasi model data logikal global
Pada langkah ke tiga ini bertujuan untuk mengkombinasikan suatu
individual model data lokal logikal ke dalam suatu model data logikal
global yang menggambarkan suatu enterprise.
Langkah 3 terdiri dari:
1. Menggabungkan model data lokal logikal menjadi global model
Tujuan dari langkah ini adalah untuk menggabungkan suatu model data
lokal logikal ke dalam suatu model data logikal global dari suatu
enterprise.
Beberapa tugas dari pendekatan ini adalah sebagai berikut:
Me-review nama dan isi dari suatu entitas / relasi dan candidate key.
Me-review nama dan isi dari relasi / foreign key.
Menggabungkan entitas / relasi dari lokal data model.
31
Memasukkan (tanpa penggabungan) entitas / relasi unik pada setiap
lokal data model.
Menggabungkan relasi / foreign key dari lokal data model.
Memasukkan (tanpa penggabungan) relasi / foreign key unik pada
setiap lokal data model.
Mengecek untuk entitas, relasi, foreign key yang hilang.
Mengecek foreign key.
Mengecek batasan integritas.
Membuat global ER / relasi diagram
Meng-update dokumentasi.
2. Memvalidasi model data logikal global
Tujuan dari langkah ini adalah untuk memvalidasi relasi yang dibuat
dari model data logikal global dengan menggunakan teknik dari
normalisasi dan juga memastikan bahwa relasi yang dibuat mendukung
transaksi.
3. Mengecek untuk kemungkinan pengembangan di masa depan
Tujuan dari langkah ini adalah untuk menentukan bagian mana yang
kelihatannya akan berubah ke masa depannya dan juga memperhatikan
supaya model data logikal global dapat mengakomodasi perubahan
tersebut.
4. Me-review model data logikal global dengan user
Tujuan dari langkah ini adalah untuk memastikan bahwa model data
logikal global itu memang merepresentasikan enterprise yang ada.
32
Hasil akhir dari perancangan logikal basisdata adalah merancang suatu
model informasi berdasarkan model data spesifik yang ada (seperti
model relasional), tetapi tidak tergantung terhadap suatu DBMS dan
perangkat keras lainnya. Logikal Basisdata merancang suatu map untuk
setiap lokal konseptual data. Jika terdapat lebih dari satu view, maka
model data lokal logikal akan dikombinasikan menjadi suatu model
data logikal global yang merepresentasikan semua view dari suatu
perusahaan.
Perancangan Basisdata Fisikal
Pengertian dari perancangan basisdata fisikal menurut Connolly (2002,
p282) ”The process of producing a description of the implementation of the
database on secondary storage; it describes the base relations, file
organization, and indexes used to achieve efficient access to the data, and
any associated integrity constraints and security measures.” Yang artinya
proses untuk menghasilkan suatu deskripsi pengimplementasian dari suatu
basisdata pada media penyimpanan secondary, yang juga akan
mendeskripsikan dasar dari suatu relasi, organisasi file, dan juga index yang
digunakan untuk mencapai suatu keefisienan pengaksesan data dan
batasan-batasan integritas serta ukuran keamanan.
Pada tahap ini ada 4 bagian pokok yaitu menerjemahkan Model data
logikal global sesuai DBMS yang dipakai (langkah 4), Merancang
Representasi Fisikal (langkah 5), Merancang tampilan Layar (langkah 6),
Merancang Mekanisme Keamanan (langkah 7).
33
Langkah 4 Model data logikal global sesuai DBMS yang dipakai
Tujuan dari langkah ini adalah untuk membuat suatu skema relasional
basisdata dari model data logikal global yang dapat diimplementasikan ke
DBMS yang dipakai.
Langkah 4 terdiri dari:
1. Merancang relasi dasar
Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan relasi dasar yang diidentifikasi dalam model data
logikal global pada DBMS yang dipakai. Untuk memulai proses
perancangan sistem basisdata fisikal, pertama-tama anda dapat
mengumpulkan dan mengasimilasikan suatu informasi tentang relasi
yang dirancang selama perancangan sistem basisdata logikal. Informasi
yang diperlukan bisa berasal dari kamus data dan definisi dari relasi
yang didefinisikan menggunakan Database Design Language (DBDL).
Untuk setiap relasi yang diidentifikasi pada model data logikal global,
definisinya terdiri dari:
Nama relasi
Suatu list untuk atribut yang simple
Primary key, alternative key, dan foreign key
Suatu daftar dari atribut turunan dan bagaimana pembuatannya
Batasan integrasi untuk setiap foreign key yang diidentifikasi.
Dari kamus data, dari setiap atributnya dapat diketahui:
34
Domain atribut tersebut yang terdiri dari tipe data, panjang, dan
berbagai batasan pada domain.
Suatu optional nilai default untuk atribut.
Apakah atribut boleh bernilai null.
2. Merancang Represantasi Data Turunan
Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan suatu data turunan pada model data logikal global
pada DBMS yang dipakai.
3. Merancang Batasan Perusahaan
Tujuan dari langkah ini adalah untuk merancang batasan perusahaan
untuk DBMS yang dipakai.
Meng-update suatu relasi yang mungkin dibatasi oleh aturan
perusahaan sesuai dengan transaksi yang sebenarnya bisa di-update.
Perancangan batasan tersebut sekali lagi tergantung pada DBMS yang
dipilih, fasilitas yang dimiliki oleh sistem dibandingkan dengan DBMS
yang lain. Pada awalnya, jika sistem tersebut mempunyai aturan sesuai
aturan standar SQL maka beberapa batasan dapat dengan mudah
diterapkan.
Langkah 5 Merancang Representasi Fisikal
Tujuan dari langkah ini adalah untuk menentukan organisasi file yang
paling optimal untuk menyimpan relasi dasar dan indeks yang diminta
35
untuk mencapai performance yang diharapkan, yaitu dengan cara
menyimpan berbagai relasi dan tuple pada secondary storage.
Langkah 5 terdiri dari:
1. Menganalisa Transaksi
Tujuan dari langkah ini adalah untuk mengerti fungsi dari suatu
transaksi yang mana akan dijalankan pada basisdata dan untuk
menganalisa transaksi yang penting.
Untuk membuat perancangan sistem basisdata fisikal efektif maka perlu
dimiliki pengetahuan mengenai transaksi atau query yang akan
dijalankan di dalam basisdata. Hal ini termasuk kuantitatif atau
kualitatif informasi. Dalam menganalisa transaksi, dapat diidentifikasi
kriteria performansi sebagai berikut:
Transaksi yang sering digunakan dan akan berdampak besar
terhadap performansi keseluruhan.
Transaksi yang merupakan transaksi bisnis yang kritis.
Durasi waktu dalam harian atau mingguan yang akan
mendapatkan banyak permintaan pada basisdata.
2. Memilih Organisasi File
Tujuan dari langkah ini adalah untuk menentukan organisasi file yang
efisien untuk setiap relasional data.
Dalam banyak kasus yang ada, suatu relasional DBMS akan
memberikan sedikit bahkan tanpa pilihan dalam memilih organisasi
file, walaupun beberapa akan mempunyai indeks yang spesifik.
36
Bagaimanapun, berikut ini beberapa organisasi file yang ada adalah
sebagai berikut:
Heap.
Hash.
Indexed Sequential Access Method (ISAM).
B+-tree.
Clusters.
3. Memilih Indeks
Tujuan dari langkah ini adalah untuk menentukan apakah penambahan
indeks akan meningkatkan performansi dari suatu sistem.
Biasanya pemilihan atribut untuk indeks adalah sebagai berikut:
Suatu atribut yang digunakan paling sering untuk operasi
penggabungan, yang akan membuat penggabungan tersebut lebih
efisien.
Suatu atribut yang digunakan paling banyak untuk mengakses
suatu record di dalam relasi yang ada.
4. Mengestimasi Kapasitas Penyimpanan yang Dibutuhkan
Tujuan dari langkah ini adalah untuk mengestimasi ukuran kapasitas
disk yang diperlukan untuk sistem basisdata.
37
Langkah 6 Merancang tampilan Layar
Tujuan dari langkah ini adalah untuk merancang tampilan user yang
diidentifikasi selama pengumpulan informasi dan analisis dari siklus hidup
aplikasi sistem basisdata.
Langkah 7 Merancang Mekanisme Keamanan
Tujuan dari langkah ini adalah untuk merancang ukuran keamanan untuk
basisdata yang telah dispesifikasi oleh user.
Definisi dari keamanan basisdata adalah suatu mekanisme yang
memproteksi basisdata dari suatu kejadian yang disengaja maupun yang
tidak disengaja.
Suatu basisdata merupakan sumber dari perusahaan yang essential yang
perlu dilindungi dengan menggunakan suatu kontrol yang memadai.
Beberapa kasus keamanan basisdata yang perlu diperhatikan, antara lain:
Pencurian data (Theft & Fraud)
Kehilangan kerahasiaan suatu data (Loss of Confidentially)
Kehilangan hak pribadi (Loss of Privacy)
Kehilangan integritas (Loss of Integrity)
Kehilangan ketersediaan data (Loss of Availability).
Hasil akhir dari perancangan fisikal basisdata adalah suatu proses yang
mendeskripsikan suatu implementasi dari suatu basisdata pada media
penyimpanan. Ini mendeskripsikan suatu relasi dasar dan struktur
penyimpanan dan metode akses yang digunakan untuk mengakses data
secara efektif, selama batasan integritas dan ukuran keamanan.
38
2.1.10 Entity Relationship Modelling
Tipe Entitas
Entity types menurut Connolly (2002, p331) Entity type is “A group of
object with the same properties, which are identified by the enterprise
as having an independent existence.” Yang berarti bahwa tipe entitas
adalah kumpulan dari objek-objek dengan properties sama yang
diartikan oleh enterprise sebagai existence yang berdiri sendiri.
Tipe Relasi
Tipe Relasi menurut Connolly (2002, p334) Relation type is “A set of
meaningful associations among entity type.” Yang berarti bahwa tipe
relasi adalah sebuah set asosiasi yang memiliki arti diantara tipe-tipe
entitas.
‘Branch memiliki staff’
Degree of Relationship type adalah banyaknya entitas yang terlibat
dalam sebuah relasi. Pada umumnya menggunakan relasi binary, yang
berarti relasi antara dua entitas saja. Ada pula relasi yang memiliki
Staff Branch
Nama Entitas
Staff Branch Has
Relationship Name
39
lebih dari dua entitas, yaitu ternary tiga entitas, dan quaternary terdiri
dari empat entitas. Tetapi ada relasi yang melibatikan satu entitas saja
yaitu relasi recursive.
Atribut
Attribute menurut Connolly (2003, p338) Attribute is “ A property of
an entity or a relationship type.” Yang berarti atribut adalah sifat-sifat
(property) dari sebuah entitas atau tipe relasi.
Kelas-kelas atribut:
Simple attribut adalah sebuah atribut yang disusun dalam satu
komponen dengan keberadaan yang berdiri sendiri. Contoh tabel staf
memiliki atribut jabatan dan gaji.
o Composite attribut adalah sebuah atribut yang disusun dalam
berberapa komponen dan setiap atribut memiliki keberadaan yang
berdiri sendiri. Contoh pada tabel pelanggan ada atribut alamat.
Pengisian alamat (Rawabelong 88, Jakarta, 45851) dapat dibagi
jalan (Rawabelong 88), kota (Jakarta), dan kodepos (45851).
o Single Valued Attribute adalah sebuah atribut yang mengatur satu
nilai untuk setiap kejadian dari sebuah tipe entitas. Contoh tabel
barang yang memiliki tipe entitas single value untuk atribut kode
barang (kd_brg) contoh atributnya NP001, maka atribut kd_brg
menunjuk single valued attribute.
o Multi-valued attribute adalah sebuah atribut yang mengatur
beberapa nilai sekaligus untuk setiap kejadian dari sebuah tipe
entitas. Contoh tabel pelanggan memiliki tipe entitas multi-valued
40
untuk atribut no telepon (telp_no) contoh atributnya 0218818831
dan 0217787798, maka atribut telp_no menunjuk multi-valued
attribute.
o Derived attrubute adalah sebuah atribut yang mewakili sebuah
nilai yang didapat dari nilai sebuah hubungan satu atribut atau
satu set atribut, tidak berguna pada entitas yang sama.
Keys
Candidate key menurut Connolly (2002, p340) Candidat key is “The
minimal set of attributes that uniquely identifies each occurrence of an
entity type.” Yang berati jumlah minimal atribut-atribut yang dapat
mengidentifikasikan setiap kejadian/record secara unik. Sebuah
candidate key yang terdiri dari beberapa atribut disebut composite key.
Primary key menurut Connolly (2002, p341) Primary key is “The
candidate key that is selected to uniquely identify each occurrence of an
entity type.” Yang berarti candidate key yang dipilih untuk meng-
identifikasikan setiap kejadian atau record dari suatu entitas secara
unik.
Structure Constrain
Batasan utama pada relationship disebut multiplicity, menurut Connolly
(2002, p344) multiplicity is “The number (or range) of possible
occurrences of an entity type that may relate to a single occurrence of
an associated entity type through a particular relationship yang berarti
bahwa multiplicity adalah jumlah (atau range) dari kejadian yang
mungkin terjadi pada suatu entitas yang terhubung ke satu kejadian dari
41
entitas lain yang berhubungan melalui suatu relationship. Ada tiga tipe
dari relasi yang berdasar pada constrain:
o One-to-One (1:1) Relationship
o One-to-Many (1:*) Relationship
o Many-to-Many (*:*) Relationship
2.1.11 Normalisasi
Normalisasi menurut Connolly (2002, p376) Normalisasi is “A technique
for producing a set of relation with desirable properties, given the data
requirements of an enterprise.” Yang berarti Normalisasi adalah suatu
teknik untuk menghasilkan sekumpulan hubungan dengan properti yang
diinginkan, memberikan kebutuhan data dari sebuah perusahaan. Tujuan
dari normalisasi adalah meminimalkan redundansi data dan update
anomalies.
Diagram ilustrasi dari relationship antara normal form
42
Bentuk normalisasi dan proses dari normalisasi:
Unnormalized Form (UNF)
Merupakan suatu table yang berisikan satu atau lebih group/data
yang berulang.
First Normal Form (1NF)
Merupakan sebuah relasi dimana setiap irisan antara baris dan
kolom berisikan satu dan hanya satu nilai.
UNF ke 1NF dengan cara:
• Pendekatan pertama, repeating group dihilangkan dengan
memasukan data yang cocok pada kolom dari baris yang
mengandung data berulang. Dimana akan dihasilkan tabel yang
mengandung nilai tunggal pada setiap baris dan kolom.
• Pendekatan kedua, repeating group dihilangkan dengan
mengisi data berulang, bersamaan dengan sebuah salinan dari
kunci atribut aslinya. Sebuah primary key diidentifikasikan pada
relasi yang baru.
Second Normal Form (2NF)
Berdasarkan pada konsep full functional dependency,
mengindikasikan bahwa, jika A dan B merupakan atribut dari
sebuah relasi, B dikatakan fully dependent terhadap A jika B
functionally dependent pada A tetapi tidak pada proper subset dari
A. Penjelasannya sebagai berikut, suatu relasi yang memiliki
composite key sebagai primary key-nya mempunyai kemungkinan
untuk memiliki partial functional dependency, dimana atribut bukan
43
primary key merupakan fungsi pada salah satu atau sebagian dari
primary key. Dalam 2NF maka setiap atribut yang merupakan
partial functional dependency harus dipisahkan ke relasi atau tabel
yang baru dengan mengikutsertakan determinantnya. Bentuk 2NF
diperoleh apabila setiap atribut bukan bagian dari primary key suatu
tabel merupakan functional dependency dari primary key tabel
tersebut.
Third Normal Form (3NF)
Berdasarkan pada konsep transitive dependency, yaitu suatu kondisi
dimana A, B dan C merupakan atribut dari sebuah relasi, maka jika
A B dan B C, maka C transitively dependent pada A melalui
B. (menegaskan bahwa A tidak functionally dependent pada B
atau C). Penjelasannya sebagai berikut, suatu tabel atau relasi
memiliki transitive dependency apabila memiliki atribut bukan
primary key yang bergantung fungsional pada atribut primary key
lainnya pada tabel tersebut. Maka setiap atribut yang transitive
dependency dipisahkan menjadi relasi yang baru dengan
megikutsertakan determinantnya. Bentuk 3NF diperoleh apabila
setiap atribut bukan primary key dalam suatu tabel merupakan
transitive dependency dari atribut bukan primary key tabel tersebut.
Boyce-Codd Normal Form (BCNF)
Normalisasi BCNF dapat dilakukan bila terdapat kondisi dimana
relasi memiliki dua atau lebih composite key dimana candidate key-
nya saling melengkapi, yang sedikitnya memiliki satu atribut pada
44
umumnya. Sebuah relasi dikatakan BCNF, jika dan hanya jika
setiap determinant adalah candidate key.
Fourth Normal Form (4NF)
Sebuah relasi dikatakan memiliki multi-value dependency apabila
terdapat dua atau lebih one to many relationship saling bebas
terdapat pada relasi tersebut. Multi-Value dependency dapat
dihilangkan dengan memisahkan masing-masing relasi one to many
menjadi sebuah tabel baru dengan mengikutsetakan determinant-
nya. Bentuk 4NF diperoleh apabila relasi tersebut telah BCNF dan
tidak terdapat multi-value dependency.
2.2 Pendekatan Pembelian dan Persediaan
2.2.1 Pembelian
Menurut Mulyadi (2001, p299) sistem akuntansi pembelian digunakan
dalam perusahaan untuk pengadaan barang yang diperlukan oleh
perusahaan. Transaksi pembelian dapat dibagi menjadi dua golongan yaitu
pembelian lokal (pemasok dari dalam negeri) dan impor (pemasok dari luar
negeri).
Fungsi dalam sistem pembelian
Ada empat fungsi yang terkait dalam sistem pembelian, yaitu:
Fungsi Gudang
Dalam sistem pembelian, fungsi gudang bertanggung jawab untuk
mengajukan permintaan pembelian sesuai dengan posisi persediaan
45
yang ada di gudang dan untuk menyimpan barang yang telah diterima
oleh fungsi penerimaan.
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.
Fungsi Penerimaan
Fungsi penerimaan bertanggung jawab unutk melakukan pemeriksaan
terhadap jenis, mutu, dan kuantitas barang yang diterima dari pemasok
guna menentukan dapat atau tidaknya barang tersebut diterima oleh
perusahaan. Fungsi ini juga bertanggung jawab untuk menerima barang
dari pembeli yang berasal dari transaksi retur penjualan.
Fungsi Akuntansi
Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi
pencata utang dan fungsi pencatat persediaan. Dalam sistem akuntansi
pembelian, fungsi pencatat utang bertanggung jawab untuk mencatat
transaksi pembelian kedalam 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. Sedangakan fungsi pencatat persediaan
bertanggung jawab untuk mencatat harga pokok persediaan barang
yang dibeli ke dalam kartu persediaan.
46
Prosedur Pembelian
Secara garis besar transaksi pembelian mencakup prosedur berikut ini:
fungsi gudang mengajukan permintaan pembelian ke fungsi pembelian,
fungsi pembelian meminta penawaran harga dari pemasok, fungsi
pembelian menerima penawaran harga dari berbagai pemasok dan
melakukan pemilihan pemasok, fungsi pembelian membuat order
pemebelian kepada pemasok yang dipilih, fungsi penerimaan menyerahkan
barang yang diterima kepada fungsi gudang untuk disimpan, fungsi
penerimaan melaporkan penerimaan barang kepada fungsi akuntansi,
fungsi akuntansi menerima faktur tagihan dari pemasok dan atas dasar
faktur dari pemasok tersebut, fungsi akuntansi mencatat kewajiban yang
timbul dari transaksi pembeliaan. Maka dapat disimpulkan bahwa jaringan
prosedur yang membentuk sistem akuntansi pembelian adalah:
Prosedur permintaan pembelian
Dalam prosedur ini fungsi gudang mengajukan permintaan
pembelian dalam formulir surat permintaan pembelian kepada
fungsi pembelian. Jika barang tidak disimpan di gudang, misalnya
untuk barang-barang langsung pakai fungsi barang mengajukan
permintaan pembelian langsung ke fungsi pembelian dengan
menggunakan surat permintaan pembelian.
Prosedur permintaan penawaran harga dan pemilihan pemasok
Dalam prosedur ini, fungsi pembelian mengirimkan surat
permintaan penawaran harga kepada para pemasok untuk
memperoleh informasi mengenai harga barang dan berbagai syarat
47
pembelian yang lain, untuk memungkinkan pemilihan pemasok
yang akan ditunjuk sebagai pemasok barang yang diperlukan oleh
perusahaan.
Prosedur order pembelian
Dalam prosedur ini, fungsi pembelian mengirim surat order
pembelian kepada pemasok yang dipilih dan memberitahukan
kepada unit-unit organisasi lain dalam perusahaan (misalnya fungsi
penerimaan, fungsi yang meminta barang dan fungsi pencatatan
utang) mengenai order pembelian yang sudah dikeluarkan oleh
perusahaan.
Prosedur penerimaan barang
Dalam prosedur ini fungsi penerimaan melakukan pemeriksaan
mengenai jenis, kuantitas, dan mutu barang yang diterima dari
pemasok dan kemudian membuat laporan penerimaan barang untuk
menyatakan penerimaan barang dari pemasok tersebut.
Prosedur pencatatan utang
Dalam prosedur ini fungsi akuntansi memeriksa dokumen-dokumen
yang berhubungan dengan pembelian (surat oreder pembelian,
laporan penerimaan barang, dan faktur dari pemasok) dan
menyelenggarakan pencatatan utang atau mengarsipkan dokumen
sumber pencatatan utang.
Prosedur distribusi pembelian
Prosedur ini meliputi distribus rekening yang didebit dari transaksi
pembelian untuk kepentingan laporan manajemen.
48
2.2.2 Persediaan
Menurut Mulyadi (2001, p553) sistem akuntansi persediaan bertujuan
mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini
berkaitan erat dengan sistem penjualan, sistem retur penjualan, sistem retur
pembelian dan sistem akuntasi biaya produksi.
Dalam perusahaan manufaktur, persediaan terdiri dari: persediaan produk
jadi, persediaan produk dalam proses, persediaan bahan baku, persediaan
bahan penolong, persediaan bahan habis pakai pabrik, dan persediaan suku
cadang. Berikut ini khusus disajikan tabel tipe persediaan suku cadang
dengan transaksi yang mempengaruhinya, dan prosedur serta sistem
akuntansi yang berkaitan.
Tipe persedian suku cadang:
No Transaksi Sistem dan prosedur yang bersangkutan
1. Pembelian Prosedur pencatatan harga pokok
persediaan yang dibeli
2. Retur Pembelian
Prosedur pencatatan harga pokok
persedian yang dikembalikan kepada
pemasok
3.
Pemakaian barang gudang (dicatat
sebagai biaya overhead pabrik
sesungguhnya, biaya administrasi
dan umum, biaya pemasaran)
Prosedur permintaan dan pengeluaran
barang gudang
49
4. Pengembalian barang gudang
Prosedur pencatatan tambahan harga
pokok persediaan karena pengembalian
barang gudang
5. Penghitungan fisik persediaan Sistem perhitungan fisik persediaan
Berikut adalah penjelasan untuk setiap prosedur yang besangkutan:
Prosedur pencatatan harga pokok persediaan yang dibeli
Dalam prosedur ini dicatat harga pokok persedian yang dibeli.
Dokumen sumber yang digunakan dalam prosedur pencatatan harga
pokok persediaan yang dibeli adalah laporan penerimaan barang
dan bukti kas keluar. Laporan penerimaan barang digunakan oleh
bagian gudang sebagai dasar pencatatan tambahan kuantitas barang
dari pembelian ke dalam kartu gudang. Bukti kas keluar yang
dilampiri dengan laporan penerimaan barang, surat order pembelian
dan faktur dari pemasok dipakai sebagai dokumen sumber dalam
pencatatan harga pokok persediaan yang dibeli dalam register bukti
kas keluar. Bukti kas keluar juga dipakai sebagai dasar pencatatan
tambahan kuantitas dan harga pokok persedian ke dalam kartu
persedian. Prosedur ini merupakan salah satu prosedur yang
membentuk sistem pembelian.
Prosedur pencatatan harga pokok persedian yang
dikembalikan kepada pemasok
Apabila persediaan yang telah dibeli dikembalikan kepada
pemasok, maka transaksi retur pembelian akan mempengaruhi
50
persediaan yang bersangkutan, yaitu mengurangi kuantitas
persediaan dalam kartu gudang yang diselenggarakan oleh bagian
gudang dan mengurangi kuantitas dan harga pokok persediaan yang
dicatat oleh bagian kartu persediaan dalam kartu persedian yang
bersangkutan. Dokumen yang digunakan adalah laporan pengiriman
barang dan memo debit. Prosedur ini merupakan salah satu prosedur
yang membentuk sistem retur pembelian.
Prosedur permintaan dan pengeluaran barang gudang
Dalam prosedur ini dicatat harga pokok persediaan bahan baku,
bahan penolong, bahan habis pakai pabrik, dan suku cadang yang
dipakai dalam kegiatan produksi dan kegiatan non produksi.
Dokumen yang dipakai adalah bukti permintaan dan pengeluaran
barang gudang. Prosedur ini merupakan salah satu prosedur yang
membentuk sistem akuntansi biaya produksi
Prosedur pencatatan tambahan harga pokok
Transaksi pengembalian barang gudang mengurangi biaya dan
menembah persediaan barang di gudang. Dokumen yang digunakan
adalah bukti pengembalian barang gudang.
Sistem perhitungan fisik persediaan
Dalam sistem ini pada umumnya digunakan oleh perusahaan untuk
menghitung secara fisik persediaan yang disimpan di gudang, yang
hasilnya digunakan untuk meminta pertanggung-jawaban bagian
gudang mengenai pelaksanaan fungsi penyimpanan dan
pertanggungjawaban bagian kartu persediaan mengenai keandalan
51
catatan persedian yang diselenggarakannya, serta untuk melakukan
penyesuaian terhadap catatan persediaan dibagian kartu persediaan.
Dalam bagian ini diuraikan sistem penghitungan fisik persediaan
yang merupakan salah satu unsur pengendalian intern melekat
terhadap persediaan.
Fungsi-fungsi dalam Sistem Persediaan
Fungsi yang dibentuk untuk melaksanakan penghitungan fisik persediaan
umumnya bersifat sementara, biasanya berbentuk panitia atau komite yang
beranggotakan karyawan yang tidak menyelenggarakan catatan akuntasi
persediaan dan tidak melaksanakan fungsi gudang. Panita penghitungan
fisik persediaan terdiri dari: pemegang kartu perhitungan fisik, penghitung
dan pengecek. Jadi dengan demikian fungsi yang terkait dalam sistem
penghitungan fisik persediaan adalah panitia penghitungan fisik persediaan,
fungsi akuntansi,dan fungsi gudang.
Berikut adalah penjelasan untuk setiap fungsi:
Panitia Penghitungan Fisik Persediaan
Panitia ini berfungsi untuk melaksanakan penghitungan fisik persediaan
dan menyerahkan hasil perhitungan tersebut kepada bagian kartu
persediaan untuk digunakan sebagai dasar adjustment terhadap catatan
persediaan dalam kartu persediaan.
Fungsi Akuntansi
Fungsi ini bertanggung jawab untuk mencantumkan harga pokok satuan
persediaan yang dihitung ke dalam daftar hasil perhitungan fisik,
52
mengkalikan kuantitas dan harga pokok per satuan yang tercantum
dalam daftar hasil penghitungan fisik, mencantumkan harga pokok total
dalam daftar hasil penghitungan fisik, melakukan adjustment terhadap
kartu persediaan berdasar data hasil perhitungan fisik persediaan, dan
membuat bukti memorial untuk mencatat adjustment data persediaan
dalam jurnal umum berdasarkan hasil penghitungan fisik persediaan.
Fungsi Gudang
Dalam sistem penghitungan fisik persediaan, fungsi gudang
bertanggung jawab untuk melakukan adjustment data kuantitas
persediaan yang dicatat dalam kartu gudang berdasarkan hasil
penghitungan fisik persediaan.
Top Related