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.