7

BAB 2

LANDASAN TEORI

2.1 Teori Umum

2.1.1 Pengertian Basis Data

Pengertian sistem basis data menurut Connoly (2002, hal 14), “Database is a

shared collection of logically related data, and description of these data, design to

meet the information needs of an organization”, dapat diartikan sebagai sistem

basis data adalah sekumpulan data yang saling berelasi secara logika dan deskripsi

data ini dirancang untuk memenuhi informasi dalam sebuah organisasi.

Pengertian sistem basis data menurut C.J Date (2000, hal 5), “A database

system is basically a computerized records keeping system, it is a computerized

system whose overall purpose is to store information and to allow users to retrieve

and update that information on demand”, dapat diartikan sebagai sistem basis data

pada dasarnya sebuah sistem yang menyimpan data-data komputer yang

merupakan sistem terkomputerisasi dan bertujuan untuk menyimpan informasi dan

mengijinkan user untuk mendapatkan kembali dan mengubah informasi

berdasarkan permintaan.

Dari pengertian tersebut penulis menyimpulkan bahwa sistem basis data

adalah sebuah sistem yang menyimpan sekumpulan data di mana entitas-entitas

tersebut saling berelasi sehingga memudahkan user dalam pengaksesan data sesuai

dengan permintaan user.

8

2.1.2 Database Lifecycle

Gambar 2.1 Database Life Cycle

Database planning

System definition

Requirements colection and analy sis

Database design

Conceptual database design

Logical database design

Physical database design

Prototyping ( optional )

Implementation

Data conversion and loading

Testing

Operational maintenance

DBMS selection Application

design

9

2.1.2.1 Database Planning

Menurut Connoly (2002, hal 273), database planning adalah kegiatan

manajemen yang mengizinkan daur hidup sistem basis data untuk bekerja

seefisien dan seefektif mungkin. Tahapan utama paling penting didalam

database planning ini adalah mendefinisikan mission statement dan mission

objectives dari proyek sistem basis data. Mission statement mendefinisikan

tujuan utama dari aplikasi sistem basis data. Mission statement membantu

dalam menjelaskan tujuan proyek sistem basis data dan menyediakan alur

yang jelas dalam pembuatan aplikasi sistem basis data seefisien dan seefektif

mungkin. Setelah mission statement didefinisikan, kegiatan selanjutnya

mengidentifikasikan mission objectives. Mission Objectives diidentifikasikan

sebagai sebuah tugas tertentu yang harus disediakan oleh sistem basis data.

2.1.2.2 System Definition

Menurut Connoly (2002, hal 274), system definition bertujuan untuk

menspesifikasi jangkauan dan batasan dari aplikasi sistem basis data, user

dan bagian aplikasi. Maksudnya sebelum memulai dalam merancang aplikasi

sistem basis data, hal paling mendasar yang dilakukan adalah

mengidentifikasikan terlebih dahulu batas sistem yang kita bangun dan

bagaimana sistem tersebut dapat berinteraksi dengan bagian yang lain dari

sistem informasi sebuah organisasi.

10

2.1.2.3 Requirements Collection and Analysis

Menurut Connolly (2002, hal 276), requirements collection and

analysis adalah kumpulan tentang analisis informasi perusahaan yang dapat

mendukung sistem basis data dan dapat digunakan untuk

mengidentifikasikan kebutuhan untuk sistem yang baru.

Informasi yang dikumpulkan untuk setiap user view ( yaitu peran

kerja atau area aplikasi perusahaan ), yaitu :

1. deskripsi data yang digunakan

2. rincian mengenai bagaimana data digunakan

3. beberapa kebutuhan tambahan yang lain untuk aplikasi sistem basis

data yang baru.

Di samping itu, ada 3 pendekatan untuk mengelola kebutuhan aplikasi

sistem basis data dengan banyak user, diantaranya :

a. Pendekatan Terpusat

Kebutuhan untuk setiap user view untuk digabung kedalam sebuah

kebutuhan untuk aplikasi sistem basis data yang baru.

b. Pendekatan View Integration

Kebutuhan untuk setiap user view digunakan untuk membangun

model data terpisah untuk merepresentasikan user view tersebut. Hasil

model data akan digabungkan nantinya pada tahapan perancangan

sistem basis data ( Database Design ).

c. Kombinasi kedua pendekatan di atas

11

2.1.2.4 Database Design

Menurut Connoly (2002, hal 279), database design adalah proses

untuk menciptakan sebuah rancangan yang mendukung mission statement

dan mission objective perusahaan untuk mendukung kebutuhan sistem basis

data.

Proses perancangan ini dibagi menjadi 3 tahap yaitu :

1. Perancangan sistem basis data konseptual

Menurut Connoly (2002, hal 419) , perancangan sistem basis data

konseptual adalah proses membangun sebuah model informasi yang

digunakan di dalam perusahaan dengan mempertimbangkan semua

fisikal.

2. Perancangan sistem basis data logikal

Menurut Connoly (2002, hal 419), perancangan sistem basis data

logikal adalah suatu proses membangun sebuah model informasi yang

digunakan dalam sebuah perusahaan berdasarkan sebuah model

spesifik tetapi bebas dari Database Management System dan

mempertimbangkan fisikal lainnya.

3. Perancangan sistem basis data fisikal

Menurut Connoly (2002, hal 419), perancangan sistem basis data

fisikal adalah suatu proses menghasilkan deskripsi dari implementasi

sistem basis data pada media sekunder yang menggunakan relasi

dasar, organisasi file, dan indeks yang digunakan untuk mengakses

data seefisien mungkin dan beberapa integritas data serta ukuran-

ukuran keamanan.

12

2.1.2.5 Database Management System Selection

Menurut Connoly (2002, hal 284), DBMS selection yang mendukung

aplikasi sistem basis data. Tahapan utama dalam pemilihan DBMS yaitu :

1. mendefinisikan persyaratan dari referensi pemilihan DBMS

2. membuat daftar dua atau tiga buah produk

3. mengevaluasi masing-masing produk

4. rekomendasi pemilihan dan laporannya

2.1.2.6 Application Design

Menurut Connoly (2002, hal 287), application design digunakan

untuk merancang tampilan user dan aplikasi program yang diterapkan serta

proses dari sistem basis data.

2.1.2.7 Prototyping (Optional)

Menurut Connoly (2002, hal 291), prototyping membangun sebuah

model kerja aplikasi sistem basis data, yang mana mengijinkan perancang

atau user untuk memvisualisasi dan mengevaluasi bagaimana tampilan akhir

yang akan dihasilkan. Tujuan utama pengembangan sebuah protyping pada

aplikasi sistem basis data adalah mengijinkan user untuk mengunakan

prototype untuk mengidentifikasi keunggulan dari sebuah sistem yang

bekerja dengan baik.

13

2.1.2.8 Implementation

Menurut Connoly (2002, hal 292), implementation menciptakan

sebuah sistem basis data yang fisik dan aplikasi perancangannya.

2.1.2.9 Data Conversion and Loading

Menurut Connoly (2002, hal 292), data conversion and loading

adalah memindahkan data dari sistem basis data yang lama ke sistem basis

data yang baru dan mengkonversi aplikasi yang lama untuk dijalankan pada

sistem basis data yang baru.

2.1.2.10 Testing

Menurut Connoly (2002, hal 293), aplikasi sistem basis data diuji

untuk mengetes kesalahan dan memvalidasi kembali kebutuhan lebih spesifik

para user.

2.1.2.11 Operational Maintenance

Menurut Connoly (2002, hal 293), operational maintenance

merupakan proses untuk mengawasai dan merawat selama sistem dijalankan.

2.1.3 Entity Relationship Modelling

2.1.3.1 Tipe Entitas

Menurut Connoly (2002, hal 331), tipe entitas adalah sekumpulan

objek dengan properti yang sama yang diidentifikasi oleh perusahaan.

14

Representasi diagramatik dari entitas :

Gambar 2.2 Representasi diagramatik tipe entitas Staff dan Branch

2.1.3.2 Tipe Hubungan

Menurut Connoly (2002, hal 334), tipe hubungan adalah adalah

sekumpulan entitas yang memiliki hubungan satu sama lain.

Relationship Occurence adalah suatu gabungan yang dapat

diidentifikasikan secara unik yang meliputi suatu kejadian dari setiap tipe

entitas yang berpartisipasi.

Gambar 2.3 Representasi tipe hubungan Branch memiliki Staff

15

2.1.3.3 Atribut

Menurut Connoly (2002, hal 338), ”Attribute is a property of an entity

or a relationship type”, dapat diartikan sebagai atribut adalah sebuah properti

dari sebuah entitas atau tipe relasi.

Atribut terdiri dari :

1. Simple dan Composite attributes

Simpel attribute adalah sebuah atribut yang terdiri dari komponen

tunggal dengan keberadaan independen (tetap).

Atribut simpel kadang disebut juga komponen atomik (tidak bisa

dibagi).

Composite attribute adalah sebuah atribut yang terdiri dari banyak

komponen dengan keberadaan independen (tetap).

2. Single-Valued and Multi-Valued Attributes

Single-valued attribute adalah sebuah atribut yang memiliki nilai

tunggal untuk masing-masing kejadian dari sebuah entitas.

Multi-valued attribute adalah atribut yang memiliki banyak nilai

untuk masing-masing kejadian dari sebuah entitas.

3. Derived Attributes

Derived attribute adalah atribut yang menggantikan sebuah nilai yang

diturunkan dari nilai atribut yang berhubungan atau kumpulan dari

atribut, tidak perlu pada jenis entitas yang sama.

16

2.1.3.4 Key

1. Candidate Key

Menurut Connoly (2002, hal 340) candidate key adalah kunci

yang secara unik atau tidak mungkin kembar atau berbeda dengan

yang lain, dapat dipakai untuk mengidentifikasikan satu baris dalam

tipe entitas.

Contoh : BranchNo adalah candidate key untuk tipe Branch

(yang dipilih sebagai primary key) dimana setiap branch mempunyai

sebuah BranchNo yang unik / tidak mungkin kembar.

2. Primary Key

Menurut Connoly (2002, hal 341) , primary key adalah

candidate key yang dipilih sebagai kunci primer untuk

mengidentifikasikan setiap entitas .

Contoh : StaffNo maksimum lima karakter (misal : SG16).

NIN (National Insurance Number) maksimum 9 karakter (misalnya =

WL220658 D) berarti primary key-nya = StaffNo, sedangkan NIN =

alternate key (candidate key yang tidak dipilih sebagai primary key).

3. Composite Key

Menurut Connoly (2002, hal 341), Composite Key adalah

candidate key yang terdiri dari dua atau lebih atribut.

Contoh : Atribut = PropertyNo, NewspaperName,

DateAdvert, Cost. Banyak property yang diiklankan dalam banyak

17

koran pada suatu tanggal tertentu. Untuk mengidentifikasikan setiap

kejadian secara unik dari entitas advert, dibutuhkan nilai pada atribut

PropertyNo, NewspaperName dan DateAdvert.

2.1.3.5 Structural Constraints (Batasan Struktural)

Menurut Connoly (2002, hal 344) tipe utama dari batasan hubungan

dinamakan multiplicity.

Multiplicity adalah jumlah kemungkinan kejadian sebuah entitas yang

mungkin berhubungan ke sebuah kejadian tunggal dari sebuah entitas yang

tergabung melalui sebuah hubungan khusus.

Hubungan binari secara umum dibedakan menjadi :

1. derajat hubungan one-to-one (1:1)

Derajat hubungan antar entitas one-to-one ( 1:1) terjadi bila tiap

anggota entitas Staff hanya boleh berpasangan dengan satu anggota

dari entitas Branch. Sebaliknya tiap anggota dari entitas Branch hanya

boleh berpasangan dengan satu anggota dari entitas Staff.

2. derajat hubungan one-to-many (1:*)

Derajat hubungan ini terjadi bila tiap anggota entitas Staff boleh

berpasangan dengan lebih dari satu anggota entitas PropertyForRent.

Sebaliknya setiap anggota entitas PropertyForRent hanya boleh

berpasangan dengan satu anggota entitas Staff.

3. derajat hubungan many-to-many (*:*)

Derajat hubungan antar entitas ini terjadi bila tiap anggota entitas

NewsPaper boleh berpasangan dengan lebih dari satu anggota entitas

18

PropertyForRent. Sebaliknya tiap anggota entitas PropertyForRent

juga boleh berpasangan dengan lebih dari satu anggota entitas

NewsPaper.

2.1.4 Normalisasi

2.1.4.1 Pengertian Normalisasi

Menurut Connoly (2002, hal 376), “Normalization is a technique for

producing a set of relations with desirable properties, given the data

requirements of an enterprise”, dapat diartikan sebagai normalisasi adalah

sebuah teknik yang menghasilkan sekumpulan relasi dengan kriteria yang

diinginkan, yang memberikan kebutuhan data dari sebuah perusahaan.

2.1.4.2 Tahap-tahap Normalisasi

Tahap-tahap normalisasi terdiri dari :

1. Unnormalized Form (UNF)

Menurut Connoly (2002, hal 387) “Unnormalized form (UNF) is a

table that contains one or more repeating groups”, dapat diartikan

sebagai UNF adalah sebuah table yang berisikan satu atau lebih

kumpulan data yang berulang (redundansi).

2. First Normal Form (1NF)

Menurut Connoly (2002, hal 388) “First normal form (1NF) is a

relation in which the intersection of reach row and column contains

one and only one value”, dapat diartikan sebagai 1NF adalah sebuah

19

relasi yang mana titik pertemuan antara setiap baris dan kolom yang

berisi satu dan hanya satu nilai.

3. Second Normal Form (2NF)

Menurut Connoly (2002, hal 391) “Second Normal Form (2NF) is a

relation that is in first normal form and every non-primary key

attribute is fully functionally dependent on the primary key”, diartikan

sebagai 2NF adalah sebuah relasi yang terdapat di dalam 1NF dan

setiap atribut yang bukan primary key bergantung pada primary key-

nya.

4. Third Normal Form (3NF)

Menurut Connoly (2002, hal 394) “Third Normal Form (3NF) is a

relation that is in first and second normal form, and in which no non-

primary key attribute is transitively dependent on the primary key”.

Dapat diartikan sebagai 3NF adalah sebuah relasi yang terdapat pada

bentuk normalisasi pertama dan kedua, yang mana atribut primary key

adalah bergantung pada primary key-nya.

2.1.5 Metodologi Perancangan Sistem Basis Data

2.1.5.1 Perancangan Sistem Basis Data Konseptual

Menurut Connoly (2002, hal 419), perancangan sistem basis data

konseptual adalah proses membangun sebuah model informasi yg digunakan

dengan mempertimbangkan semua fisikal

Langkah 1: Perancangan sistem basis data konseptual

20

Bertujuan untuk membangun model data konseptual dari kebutuhan

data perusahaan

1.1 Mengidentifikasi tipe-tipe entitas

Bertujuan untuk mengidentifikasikan tipe entitas yang akan

dibangun.

Langkah pertama dalam membangun model data konseptual

adalah dengan mendefinisikan objek-objek utama user. Objek-objek

ini merupakan tipe-tipe entitas untuk model tersebut. Salah satu

metode mengidentifikasikan entitas adalah dengan memeriksa

spesifikasi kebutuhan user dengan mengidentifikasikan kata benda.

Contoh tipe entitas adalah staff, mata kuliah, dosen, mahasiswa, dan

lain-lain. Seteah tipe-tipe entitas tersebut diidentifikasikan, pemberian

nama untuk tiap-tiap entitas haruslah jelas bagi user. Nama dan

deskripsi entitas sebaiknya disimpan pada kamus data. Jika sebuah

entitas dikenal dengan nama lain yg disebut dengan sinonim atau

alias, maka disimpan juga pada kamus data.

1.2 Mengidentifikasi tipe-tipe hubungan antar entitas

Bertujuan mengidentifikasikan relasi-relasi penting yang ada di

antara tipe entitas yang sudah diidentifikasikan.

Untuk mengidentifikasikan relasi dapat dilakukan dengan cara

mencari kata kerja pada spesifikasi kebutuhan user. Contoh : staff

manage propertyforRent, privateOwner owns PropertyForRent. Pada

21

umumnya relasi bersifat biner, yaitu relasi tersebut berada hanya

diantara dua tipe entitas. Namun perlu juga diperhatikan adanya relasi

kompleks yang melibatkan lebih dari tipe entitas dan relasi rekursif

yang melibatkan hanya satu tipe entitas. Setelah mengidentifikasikan

relasi, langkah selanjutnya adalah menentukan multiplicity setiap

relasi. Batasan multiplicity digunakan untuk memeriksa dan

memelihara kualitas data. Selain itu harus juga diperiksa adanya fan

traps dan chasm traps dan setiap relasi harus berpartisipasi minimal

satu relasi. Deskripsi relasi dan batasan-batasan multiciplity harus

disimpan dalam kamus data.

1.3 Mengidentifikasi dan mengasosiasikan atribut-atribut dengan tipe-tipe

entitas atau hubungan antar entitas

Bertujuan untuk mengidentifikasikan atribut terhadap entitas

atau relasi biasanya disebut dicari kata benda atau frase kata benda

dari spesifikasi kebutuhan user.

Ada 3 jenis attribute yaitu :

1. simple atau composite attribute

2. single atau multivalue attribute

3. derived attribute

1.4 Menentukan domain attribut

Bertujuan utnuk menentukan batasan atribut di model data

konseptual lokal.

22

Domain adalah kumpulan nilai-nilai yang diizinkan untuk satu

atau lebih atribut. Contoh domain untuk atribut ”Jenis Kelamin” pada

tabel ”staff” adalah sebuah karakter tunggal yang yang bernilai hanya

”L” (untuk laki-laki) atau ’P” (untuk perempuan). Sebuah model data

yang baik menspesifikasikan domain untuk setiap atribut dan

meliputi:

1. Kumpulan nilai – nilai yang diizinkan untuk atribut

2. Ukuran dan format atribut

Setelah domain atribut diidentifikasikan, nama-nama domain

dan karakteristiknya disimpan pada kamus data.

1.5 Menentukan atribut candidate dan primary key

Candidate key adalah kunci yang unik atau tidak mungkin

kembar atau berbeda dengan yang lain, dapat dipakai untuk

mengidentifikasikan satu baris dalam tipe entitas.

Composite key adalah candidate key yang terdiri dari dua atau

lebih atribut.

Primary key adalah candidate key yang dipilih sebagai kunci

primer untuk mengidentifikasikan setiap entitas.

Alternate key adalah candidate key yang tidak terpilih menjadi

primary key.

Foreign key adalah sebuah atribut atau kumpulan atribut dalam

suatu relasi yang sama dengan candidate key dari beberapa relasi

(mungkin relasi yang sama).

23

1.6 Mempertimbangkan penggunaan konsep enhanced modeling

Bertujuan untuk mempertimbangkan konsep enhanced

modeling seperti spesialisasi atau generalisasi, agregasi dan

komposisi. Pada tahap ini jika memilih pendekatan spesialisasi,

diusahakan untuk memperhatikan perbedaan antara entitas dengan

mendefiniskan satu atau lebih subclass dari sebuah entitas superclass.

Jika menggunakan pendekatan generalisasi, diusahakan untuk

mengidentifikasikan fitur-fitur umum antar entitas untuk

mendefinisikan sebuah entitas superclass generalisasi. Pendekatan

agregasi digunakan untuk merepresentasikan hubungan ”mempunyai

suatu” atau ”bagian dari” antara tipe-tipe entitas, dimana yang satu

merepresentasikan ”keseluruhan” dan yang lainnya sebagai

”bagiannya”. Komposisi digunakan untuk merepresentasikan sebuah

asosiasi antara tipe-tipe entitas dimana terdapat kepemilikan yang kuat

dan keterhubungan antara ”keseluruhan” dan ”bagiannya”.

1.7 Memeriksa model terhadap redundansi

Bertujuan untuk memeriksa adanya redundansi pada model.

Ada 2 aktifitas pada tahap ini, yaitu:

1. Memeriksa kembali relasi one-to-one ( 1:1)

Pada saat mengidentifikasi entitas, mungkin akan

teridentifikasi dua entitas yang merepresentasikan objek yang

sama pada perusahaan. Untuk kejadian ini, kedua entitas

24

tersebut harus digabungkan . Jika primary key beberda, pilih

salah satu primary key tersebut dan biarkan yang lain sebagai

alternate key.

2. Menghilangkan relasi yang redundansi

Suatu relasi dikatakan dedundansi jika informasi yang sama

dapat diperbolehkan melalui relasi yang lain. Data model yang

baik seminimal mungkin tidak memiliki relasi yang redundan.

1.8 Memvalidasikan model konseptual lokal terhadap transaksi user.

Bertujuan untuk memastikan bahwa model konseptual

mendukung kebutuhan transaksi yang diperlukan bagi view. Dua

pendekatan yang mungkin dilakukan untuk memastikan bahwa model

data konseptual lokal mendukung transaksi yang dibutuhkan adalah :

1. Mendeskripsikan transaksi

Memeriksa apakah semua informasi (entitas, relasi, dan

attributnya) yang dibutuhkan oleh setiap transaksi telah

disediakan oleh model, dengan mendokumentasikan sebuah

deskripsi dari kebutuhan transaksi.

2. Memakai jalur transaksi

Memvalidasi model data terhadap transaksi yang dibutuhkan

yang melibatkan diagram yang merepresentasikan jalur setiap

transaksi dalam diagram ER.

25

1.9 Meninjau kembali model data konseptual dengan pengguna.

Bertujuan untuk meninjau kembali model data konseptual lokal

dengan user untuk memastikan bahwa model representasi telah sesuai.

Pada langkah ini data konseptual lokal ditinjau ulang oleh user.

Model data konseptual meliputi diagram ER dan dokumentasi

pendukung yang menggambarkan model data tersebut. Jika terjadi

anomali pada model data, maka harus dilakukan perubahan yang

mungkin memerlukan pengulangan langkah-langkah sebelumnya.

Proses ini terus diulang sampai model data benar-benar menjadi

representasi aktual dari perusahaan.

Gambar 2.4 Contoh Entity Relationship Diagram Konseptual

26

2.1.5.2 Perancangan Sistem Basis Data Logikal

Menurut Connoly (2002, hal 419) , perancangan sistem basis data

logikal adalah suatu proses membangun model informasi yang digunakan

dalam sebuah perusahaan berdasarkan sebuah model spesifik tetapi bebas

dari Database Management System dan mempertimbangkan fisikal lainnya.

Langkah 2: Membangun dan memvalidasi model data logikal lokal untuk

setiap view.

Bertujuan untuk membangun model data logikal dari model data

konseptual lokal yang merepresentasikan view tertentu dari perusahaan dan

memvalidasikan model tersebut untuk menjamin agar strukturnya benar

(menggunakan teknik normalisasi) dan mendukung transaksi yang

dibutuhkan.

2.1 Memperoleh relasi untuk model data logikal lokal

Bertujuan untuk membangun relasi untuk model data logikal

lokal untuk merepresentasi entitas, relasi dan attribut yang telah

diidentifikasikan.

Pembagian relasi yang dapat dihasilkan dari sebuah model data

diantaranya :

- tipe entitas kuat

- tipe entitas lemah

- tipe relasi binari one-to-one ( 1:1)

- tipe relasi one to many ( 1:*)

27

- tipe relasi many to many ( *:*)

- tipe relasi superclass/subclass

- tipe relasi kompleks

- attribut multivalue

2.2 Memvalidasikan relasi menggunakan normalisasi

Bertujuan untuk memvalidasikan relasi di dalam model data

logikal lokal menggunakan teknik normalisasi. Proses normalisasi

terdiri dari Unnormal Form ( UNF ), First Normal Form ( 1NF ),

Second Normal Form ( 2NF) dan Third Normal Form (3NF).

2.3 Memvalidasikan relasi terhadap transaksi pengguna

Bertujuan untuk memastikan bahwa relasi di dalam model data

logikal lokal mendukung kebutuhan transaksi bagi view. Validasi

transaksi seperti ini sudah dilakukan pada langkah 1.8 namun

dilakukan kembali untuk mengecek relasi-relasi yang diciptakan pada

rancangan logikal juga mendukung transaksi user.

2.4 Mengecek batasan integritas

Bertujuan untuk mengecek batas integritas yang

direpresentasikan ke dalam model data logikal.

Ada 5 tipe batasan integritas yaitu :

1. Data yang dibutuhkan

28

Beberapa atribut harus memiliki sebuah nilai yang valid (tidak

mengandung NULL). Contoh : setiap anggota staff harus

memiliki hubungan posisi jabatan (seperti supervisor atau

asisten).

2. Batasan domain atribut

Setiap attribute memiliki sebuah domain. Dengan kata lain

sekumpulan nilai harus sah. Contoh : jenis kelamin untuk

anggota staff boleh ”M” atau ”F”, jadi domain atribut untuk

jenis kelamin adalah karakter tunggal. Batasan ini harus

diidentifikasi dalam kamus data.

3. Integritas Entitas

Primary key dari sebuah entity tidak boleh NULL. Contoh

setiap baris dari relasi staff harus memiliki nilai untuk attribut

primary key.

4. Integritas Referensial

Foreign key menghubungkan setiap baris dari relasi anak untuk

baris ke dalam relasi induk dengan mencocokan kandidat key-

nya. Referential Integrity maksudnya adalah jika foreign key

berisi sebuah nilai yang nilainya harus menunjukkan baris yang

ada pada relasi induknya.

5. Batasan perusahaan

Terakhir, kita memperhatikan batasan perusahaan. Mengupdate

entitas mungkin dikontrol oleh yang memiliki hak pembatas.

29

2.5 Meninjau kembali model data logikal lokal dengan user

Bertujuan untuk memastikan bahwa model data logikal lokal

dan dokumen pendukung yang mendeskripsikan model yang sesuai

dengan view.

Model data logikal telah selesai dan didokumentasikan. Pada

tahapan ini model logikal dan dokumentasi tersebut ditinjau ulang

dengan user.

2.6 Menggabungkan model data logikal ke dalam global

Bertujuan untuk menggabungkan model data logikal lokal ke

dalam model data logikal global yang merepresentasikan semua user

view dari sebuah sistem basis data.

Kegiatan dalam tahapan ini terdiri dari :

1. menggabungkan model data logikal lokal ke dalam model

global.

2. memvalidasikan model data logikal global.

3. meninjau kembali model data logikal global dengan user.

2.7 Mengecek untuk perkembangan masa yang akan datang

Bertujuan untuk menentukan apakah ada perubahan dan

menilai apakah model data logikal bisa menampung perubahan ini.

Perancangan sistem basis data logikal sangat memperhatikan

apakah model data logikal (boleh atau tidak boleh untuk

30

dikembangkan berdasarkan langkah 2.6) yang digunakan untuk

mendukung perkembangan di masa akan datang.

Gambar 2.5 Contoh Entity Relationship Diagram Logikal

31

2.1.5.3 Perancangan Sistem Basis Data Fisikal

Menurut Connoly (2002, hal 419), Perancangan sistem basis data

fisikal adalah suatu proses menghasilkan deskripsi dari implementasi sistem

basis data pada media sekunder yang menggunakan relasi dasar, organisasi

file dan indeks yang digunakan untuk mengakses data seefisien mungkin dan

beberapa integritas data serta batasan keamanannya.

Langkah 3: Menerjemahkan model data logikal global untuk target DBMS.

Bertujuan untuk menghasilkan skema basis data relasional dari model

data logikal global yang dapat diimplementasikan pada DBMS pilihan.

Bagian pertama dari proses ini memerlukan perbandingan informasi yang

dikumpulkan selama perancangan sistem basis data logikal dan

didokumentasikan pada kamus data.

Bagian kedua dari proses ini menggunakan infromasi tersebut untuk

menghasilkan desain relasi dasar. Proses ini memerlukan pengetahuan yang

mendalam mengenai fungsionalitas yang ditawarkan oleh DBMS pilihan.

Merancang relasi dasar

Bertujuan untuk memutuskan bagaimana relasi dasar

diidentifikasikan pada model data logikal global ke dalam target

DBMS.

Untuk memulai perancangan fisikal pertama kita harus

menyusun dan memahami informasi tentang relasi yang menghasilkan

perancangan sistem basis data logikal. Kebutuhan informasi ini bisa

32

berupa kamus data dan definisi relasi yang menggambarkan

penggunaan database design language ( DBDL ).

Merancang representasi dari data yang telah didapat

Bertujuan untuk memutuskan bagaimana merepresentasikan

semua data yang telah didapat pada data logikal global ke dalam

DBMS pilihan.

Atribut yang nilainya dapat diperoleh dengan memeriksa nilai

dari atribut lain disebut atribut yang didapat atau atribut hasil

kalkulasi. Langkah pertama adalah memeriksa model data logikal dan

kamus data untuk menghasilkan daftar semua atribut yang didapat.

Pada perancangan sistem basis data fisikal, atribut yang telah

diperoleh dapat disimpan ke dalam sistem basis data atau

dikalkulasikan setiap kali diperlukan. Perancang harus memperhatikan

biaya tambahan untuk menyimpan data yang telah diperoleh dan

menjaganya agar tetap konsisten dengan data operasional dari mana

data tersebut diperoleh atau biaya untuk mengkalkulasikan atribut

tersebut setiap kali diperlukan.

Merancang batasan perusahaan

Bertujuan untuk merancang batasan perusahaan pada DBMS

pilihan.

33

Perubahan terhadap data dapat dibatasi oleh aturan perusahaan

yang mengatur transaksi dalam ”dunia nyata.” Perancangan batasan

ini tergantung pada pemilihan DBMS yang akan digunakan.

Beberapa DBMS menyediakan fasilitas ini namun ada juga

yang tidak menyediakannya, sehingga untuk menentukan batasan

harus dilakukan pada progam aplikasi.

Langkah 4 : Perancangan sistem basis data fisikal

Bertujuan untuk menentukan optimal organisasi file untuk menyimpan

relasi dasar dan indeks yang dibutuhkan untuk mencapai hasil yang baik

yaitu dengan cara yang mana relasi dan baris akan dipegang ditempat

penyimpanan sekunder.

4.1 Menganalisis transaksi

Bertujuan untuk memahami fungsi transaksi yang akan

dijalankan pada sistem basis data dan analisis transaksi yang penting.

Dalam analisis transaksi terdapat beberapa kriteria diantaranya:

1. Transaksi yang sering dijalankan akan memiliki pengaruh yang

penting pada hasil.

2. Transaksi yang kritis untuk beroperasi pada bisnis.

3. Waktu selama harian atau mingguan ketika dapat

meningkatkan permintaan pada sistem basis data.

34

4.2 Memilih organisasi file

Bertujuan untuk menentukan organisasi file yang efisien untuk

setiap relasi dasar.

Salah satu tujuan utama dalam perancangan sistem basis data

fisikal adalah untuk menyimpan dan mengakses data dengan jalur

yang efisien.

4.3 Memilih indeks

Bertujuan untuk menentukan apakah penambahan indeks akan

meningkatkan performa dari sistem.

Kriteria memilih atribut untuk ordering atau clustering tuple

antara lain :

a. Atribut yang paling sering digunakan untuk operasi join

sehingga operasi join tersebut mejadi lebih efisien atau

b. Atribut yang sering digunakan untuk mengakses tuple pada

sebuah tabel berdasarkan urutan atribut tersebut.

Jika urutan ordering yang dipilih adalah key dari tabel, indeks

akan menjadi primary index. Namun jika bukan index key akan

menjadi clustering index. Indeks sekunder menyediakan sebuah

mekanisme untuk menspesifikasikan key tambahan untuk relasi dasar

yang dapat digunakan untuk mengambil data lebih efisien. Beberapa

pertambahan dalam menggunakan indeks sekunder meliputi:

35

a. Menambahkan sebuah indeks record untuk setiap indeks

sekunder setiap kali sebuah tuple dimasukan ke dalam sebuah

tabel.

b. Mengupdate indeks sekunder ketika tuple yang bersangkutan

pada tabel tersebut diubah.

c. Penambahan kapasitas disk untuk menyimpan indeks sekunder.

d. Kemungkinan penurunan performa selama optimasi query

karena query optimizer mempertimbangkan semua indeks

sekunder sebelum memilih strategi eksekusi yang optimal.

4.4 Memperkirakan kebutuhan kapasitas disk

Bertujuan untuk memperkirakan jumlah kapasitas disk yang

dibutuhkan oleh sistem basis data.

Memperkirakan penggunaan kapasitas disk tergantung pada

DBMS yang dipakai dan perangkat keras yang digunakan untuk

mendukung sistem basis data. Secara umum estimasi didasarkan pada

ukuran setiap baris dan jumlah baris dalam setiap tabel. Selain itu

perlu juga dipertimbangkan apakah setiap tabel akan bertumbuh dan

sebaiknya akan faktor pertumbuhan ini dimasukan ke dalam

perhitungan kebutuhan kapasitas disk.

36

Langkah 5 : Merancang User View

Bertujuan untuk merancang user view yang diidentifikasi selama

tahapan pengumpulan kebutuhan dan analisis dari siklus aplikasi sistem basis

data.

User view mendefinisikan apa yang dibutuhkan dari aplikasi sistem

basis data dari sudut pandang jabatan tertentu (misalnya manajer atau

supervisor) atau area aplikasi perusahaan (seperti pemasaran, personalia atau

pengendalian stok).

Perancangan dari user view individual harus didokumentasikan secara

lengkap.

Langkah 6 : Merancang mekanisme keamanan.

Bertujuan untuk merancang mekanisme keamanan untuk sistem basis

data yang dispesifikasi oleh user.

- Keamanan sistem

Meliputi akses dan penggunaan sistem basis data pada tingkatan

sistem seperti username dan password.

- Keamanan data

Meliputi akses dan penggunaan objek sistem basis data (seperti relasi

dan view) dan tindakan yang memungkinkan user untuk memanipulasi

objek.

37

Langkah 7: Mempertimbangkan penggunaan dari redundansi kontrol

Bertujuan untuk menentukan apakah penerapan redundansi dalam

situasi terkontrol dengan mengurangi aturan normalisasi akan meningkatkan

performa sistem.

Seringkali rancangan sistem basis data yang ternormalisasi tidak

mampu menyediakan efisiensi pemrosesan yang maksimum sehingga

denormalisasi dilakukan untuk mencapai performa yang diinginkan.

Namun yang perlu dipertimbangkan beberapa faktor berikut :

a. denormalisasi menyebabkan implementasi menjadi lebih kompleks.

b. denormalisasi seringkali mengurangi fleksibilitas.

c. denormalisasi dapat mempercepat pengambilan data namun

memperlambat update.

Denormalisasi untuk mempercepat transaksi yang sering dilakukan

atau transaksi kritis dapat diaplikasikan pada situasi berikut :

1. Menggabungkan one-to-one ( 1:1)

Menguji kembali relasi one-to-one (1:1) menentukan efek dari

kombinasi relasi ke dalam relasi tunggal. Kombinasi seharusnya

hanya memperhatikan untuk relasi yang sering direlasi dan yang tidak

sering direlasikan.

2. Menduplikasikan atribut-atribut yang bukan kunci di dalam relasi one-

to-many (1:*) untuk mengurangi join.

3. Menduplikasi atribut-atribut foreign key di dalam relasi one-to-many

(1:*)

38

4. Menduplikasikan atribut dalam many-to-many (*:*) relasi untuk

mengurangi join.

5. Mempelajari kelompok repetisi

6. Membuat tabel kutipan

7. Membagi relasi

Langkah 8 : Mengawasi dan menggunakan sistem operasional

Bertujuan untuk mengawasi sistem operasional dan meningkatkan

performa sistem untuk memperbaiki keputusan rancangan yang kurang tepat

atau adanya perubahan kebutuhan.

Perancangan awal sistem basis data secara fisikal seharusnya tidak

dianggap statis, melainkan harus dipertimbangkan sebagai sebuah perkiraan

dari kinerja operasional. Setelah perancangan awal telah diimplementasikan,

maka diperlukan pengawasan sistem dan penyetelannya sebagai hasil dari

pengamatan kinerja dan perubahan kebutuhan.

2.1.6 Data Flow Diagram

Menurut Whitten (2004, hal 334), “Data Flow Diagram ( DFD) is a tool

that depicts the flow of data through a system and the work or processing

performed by that system”, dapat diartikan sebagai DFD adalah sebuah alat yang

menggambarkan aliran data sampai sebuah sistem selesai dan kerja atau proses dan

dilakukan dalam sistem tersebut. Sinonimnya adalah bagan bubble, grafik

transformasi, and model proses.

Ada 4 komponen dalam DFD yaitu:

39

1. External Agent

Menurut Whitten (hal 363), “External agents are define a person, an

organization unit, another system or another organizatoin that lies outside

the scope of the project but that interacts with the system being studied”,

dapat diartikan sebagai external agent adalah mendefinisikan orang, sebuah

unit organisasi , sistem lain atau organisasi lain yang berada di luar sistem

projek tetapi yang mempengaruhi kerja sistem.

Menurut Whitten (hal 347) ada beberapa bentuk external agent :

a. bentuk Gain dan Sarson (digunakan dalam skripsi ini)

Gambar 2.6 Bentuk External Agent Berdasarkan Gain dan Sarson

b. bentuk DeMarco/Yourdon

Gambar 2.7 Bentuk External Agent Berdasarkan DeMarco/Yourdon

c. bentuk SSADM/IDEF0

Gambar 2.8 Bentuk External Agent Berdasarkan SSADM/IDEF0

40

2. Process

Menurut Whitten (hal 347), ”Process is a work perform on , all in

response , incoming data flows or condition”, dapat diartikan sebagai proses

adalah penyelenggaraaan kerja atau jawaban, datangnya aliran data atau

kondisinya.

Menurut Whitten (hal 347) ada beberapa bentuk proses diantaranya :

a. Bentuk Gain and Sarson

Gambar 2.9 Bentuk Proses Berdasarkan Gain dan Sarson

b. bentuk DeMarco/Yourdon

Gambar 2.10 Bentuk Proses Berdasarkan DeMarco/Yourdon

c. bentuk SSADM/IDEF0

Gambar 2.11 Bentuk Proses Berdasarkan SSADM/IDEF0

41

3. Data Stores

Data Stores is an “inventory” of data , dapat diartikan sebagai data

store adalah tempat penyimpanan data.

Menurut Whitten (hal 366) ada beberapa bentuk data stores

diantaranya:

Bentuk Gain and Sarson

Gambar 2.12 Bentuk Data Store Berdasarkan Gain dan Sarson

a. Bentuk DeMarco/Yourdon

Gambar 2.13 Bentuk Data Store Berdasarkan DeMarco/Yourdon

b. Bentuk SSADM/IDEF0

Gambar 2.14 Bentuk Data Store Berdasarkan SSADM/IDEF0

4. Data Flow

Data Flow is represents an input of data to a process or the output of

data (or information) from a process, dapat diartikan sebagai data flow

42

adalah merepresentasikan sebuah input data ke dalam sebuah proses atau

output dari data (atau informasi) dari sebuah proses.

Bentuk data flow :

Nama data flow

Jenis-jenis DFD adalah sebagai berikut :

1. Level 0 (Diagram Context)

Level ini terdapat sebuah proses yang berada di posisi pusat.

2. Level 1 (Diagram Nol)

Level ini merupakan sebuah proses yang terdapat di level nol yang

dipecahkan menjadi beberapa proses lainnya.

3. Level 2 (Diagram Rinci)

Pada level ini merupakan diagram yang merincikan diagram dari level

1.

• Tanda ’*’ digunakan hanya jika proses tersebut tidak bisa

dirincikan lagi. Contoh : 2.0*, artinya proses level rendah

yang tidak bisa dirincikan lagi.

• Penomeran yang dilakukan berdasarkan urutan proses.

2.1.7 State Transition Diagram

State Transition Diagram (STD) adalah sebuah perangkat pemodelan yang

menggambarkan sifat ketergantungan terhadap waktu pada sistem. Menurut

Pressman (2001, hal 317), STD digunakan untuk mengidentifikasikan

43

sebagaimana sistem harus berperilaku seperti resiko dari kejadian eksternal. Untuk

mencapai hal ini STD menampilkan berbagai jenis model perilaku dari hasil dan

tingkah laku yang mana transisi dibuat dari satu step ke step yang lain. Penyajian

STD merupakan landasan dasar untuk menentukan perilaku. Biasanya di dalam

STD digunakan notasi seperti :

1. Active

• State, simbolnya persegi panjang

State adalah kumpulan keadaan atau atribut yang memberi perincian

seseorang atau benda pada waktu dan kondisi tertentu. Contohnya

seperti :

Proses user mengisi password, menentukan instruksi berikutnya.

Simbol state :

• Transition State / Perubahan State, simbolnya tanda panah berarah.

Simbol transition state :

• Condition

Kejadian pada lingkungan eksternal yang bisa terdeteksi oleh sistem

Hal ini akan mengakibatkan perubahan pada state dari keadaan state

menunggu X ke state menunggu Y. Contohnya seperti interupt signal

maupun data.

44

• Action

Action adalah hal yang dilakukan sistem apabila ada perubahan state

atau merupakan reaksi terhadap kondisi.

Action menghasilkan keluaran dari tampilan pesan, cetakan atau alat

output lainnya.

2. Passive

Sistem ini tidak melakukan kontrol terhadap lingkungan, akan tetapi

lebih bersifat menerima data atau memberi reaksi saja (sistem yang

menerima atau mengumpulkan data dari sinyal yang dikirim oleh satelit ).

Berikut adalah gambar STD yang sederhana :

Gambar 2.15 Contoh State Transition Diagram yang Sederhana

2.2 Teori Khusus

2.2.1 Pembelian

Menurut Mulyadi (2001, hal 299) sistem akuntansi pembelian digunakan

dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan.

State X

State Y

45

Transaksi pembelian dapat digolongkan menjadi dua : pembelian lokal dan impor.

Pembelian lokal adalah pembelian dari pemasok dalam negeri, sedangkan impor

adalah pembelian dari pemasok luar negeri.

Menurut Mulyadi (2001, hal 299), fungsi yang terkait dalam sistem

akuntansi pembelian adalah :

1. Fungsi Gudang

Dalam sistem akuntansi pembelian, fungsi gudang bertanggung jawab untuk

mengajukan permintaan pembelian sesuai dengan posisi persediaan yang

ada di gudang untuk menyimpan barang yang telah diterima oleh fungsi

penerimaan. Untuk barang-barang yang langsung pakai (tidak

diselenggarakan persediaan barang di gudang), permintaan pembelian

diajukan oleh pemakai barang.

2. Fungsi pembelian

Fungsi pembelian bertanggung jawab untuk memperoleh informasi

mengenai harga barang, menentukan pemasok yang dipilih dalam

pengadaan barang, dan mengeluarkan order pembelian kepada pemasok

yang dipilih.

3. Fungsi penerimaan

Dalam sistem akuntansi pembelian, fungsi ini bertanggung jawab untuk

melakukan pemeriksaan terhadap jueni, mutu dan kuantitas barang yang

diterima pemasok guna menentukana dapat atau tidaknya barang tersebut

diterima oleh perusahaan. Fungsi ini juga bertanggung jawab untuk

menerima barang dari pembeli yang berasal dari transaksi retur penjualan.

4. Fungsi akuntansi

46

Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi

pencatat utang dan fungsi pencatatan persediaan. Dalam sistem akuntansi

pembelian, fungsi pencatat utang bertanggung jawab untuk mencatat

transaksi pembelian ke dalam register bukti kas keluar dan untuk

menyelenggarakan arsip dokumen sumber (bukti kas keluar) yang berfungsi

sebagai catatan utang atau menyelenggarakan kartu utang sebagai buku

pembantu utang. Dalam sistem akuntansi pembelian, fungsi pencatatan

persediaan bertanggung jawab untuk mencatat harga pokok persediaan

barang yang dibeli ke dalam kartu persediaan.

Menurut Mulyadi (2001, hal 301-303), jaringan prosedur yang membentuk

system pembelian adalah :

• Prosedur permintaan pembelian

Dalam prosedur ini, fungsi gudang mengajukan permintaan pembelian

dalam formulir serta peermintaan kepada fungsi pembelian

• Prosedur permintaan penawaran harga dan pemilihan pemasok

Fungsi pembelian mengirim surat permintaan penawaran harga kepada

pemasok untuk memperolhe informasi mengenai harga barang dan berbagai

syarat pembelian yang lain untuk memungkinkan pemilihan pemasok yang

akan ditunjuk sebagai pemasok barang yang diperlukan oleh perusahaan.

• Prosedur order pembelian

Fungsi pembelian mengirim surat order pembelian kepada pemasok yang

dipilih dan memberitahukan kepada unit-unit organisasi lain dalam

47

perusahaan mengenai order pembelian yang telah dikeluarkan oleh

perusahaan.

• Prosedur penerimaan barang

Fungsi penerimaan barang melakukan pemeriksaan mengenai jenis,

kuantitas dan mutu bahan yang diterima dari pemasok dan kemudian

membuat laporan penerimaan barang untuk menyatakan penerimaan barang

dari pemasok tersebut.

• Prosedur pencatatan hutang

Fungsi akuntansi memeriksa dokumen-dokumen yang berhubungan dengan

pembelian (SOP, laporan penerimaan barang, faktur dari pemasok) dan

menyelenggarakan pencatatan ulang atau pengarsipan dokumen sumber

sebagai catatan hutang.

• Prosedur distribusi pembelian

Prosedur ini meliputi distribusi rekening yang didebet dari transaksi

pembelian untuk kepentingan laporan manajemen.

Menurut Mulyadi (2001, hal 335), sistem retur pembelian digunakan dalam

perusahaan untuk pengembalian barang yang sudah dibeli kepada pemasoknya.

Adapun barang yang sudah diterima dari pemasok terkadang tidak sesuai dengan

barang yang dipesan menurut surat order pembelian. Ketidaksesuaian itu terjadi

kemungkinan karena barang yang diterima tidak cocok dengan spesifikasi yang

tercantum dalam surat order pembelian, barang mengalami kerusakan dalam

48

pengiriman, atau barang diterima melewati tanggal pengiriman yang dijanjikan

oleh pemasok. Fungsi yang terkait dalam sistem retur pembelian adalah :

1. Fungsi Gudang

Fungsi ini bertanggung jawab untuk menyerahkan barang kepada fungsi

pengiriman seperti yang tercantum dalam tembusan memo debit yang

diterima dari fungsi pembelian.

2. Fungsi Pembelian

Fungsi ini bertanggung jawab untuk mengeluarkan memo debit untuk retur

pembelian.

3. Fungsi pengiriman

Fungsi ini bertanggung jawab untuk mengirimkan kembali barang kepada

pemasok sesuai dengan perintah retur pembelian dalam memo debit yang

diterima dari fungsi pembelian.

4. Fungsi Akuntansi

Fungsi ini bertanggung jawab untuk mencatat :

a. Transaksi retur pembelian dalam jurnal retur pembelian atau jurnal

umum.

b. Berkurangnya harga pokok persediaan karena retur pembelian dalam

kartu persediaan.

c. Berkurangnya utang yang timbul dari transaksi retur pembelian dalam

arsip bukti kas keluar yang belum dibayar atau dalam kartu utang.

Menurut Mulyadi (2001, hal 339), sistem retur pembelian terdiri dari

jaringan prosedur berikut ini :

49

1. Prosedur perintah retur pembelian

Retur pembelian terjadi atas perintah fungsi pembelian kepada fungsi

pengiriman untuk mengirimkan kembali barang yang telah diterima oleh

fungsi penerimaan kepada pemasok yang bersangkutan. Dokumen yang

digunakan oleh fungsi pembelian untuk memerintahkan fungsi pengiriman

mengembalikan barang ke pemasok adalah memo debit.

2. Prosedur pengiriman barang ke pemasok

Fungsi pengiriman barang kepada pemasok sesuai dengan perintah retur

pembelian yang tercantum dalam memo debit dan membuat laporan

pengiriman barang untuk transaksi retur pembelian tersebut.

3. Prosedur pencatatan utang

Fungsi akuntansi memeriksa dokumen-dokumen yang berhubungan dengan

retur pembelian dan mnyelenggarakan pencatatan berkurangnya utang

dalam kartu utang atau mengarsipkan dokumen memo debit sebagai

pengurang utang.

2.2.2 Persediaan

2.2.2.1 Definisi Persediaan

Menurut Mulyadi ( 2001, hal 553 ), dalam perusahaan dagang,

persediaan hanya terdiri dari persediaan barang dagangan, yang merupakan

barang yang dibeli untuk dijual kembali.

50

2.2.2.2 Jenis – jenis Persediaan

Menurut Thomas R. Dyckman (2001, hal 378), persediaan terdiri dari

barang-barang yang dimiliki suatu bisnis dan disimpan baik untuk digunakan

membuat produk atau sebagai produk yang siap untuk dijual dan dapat

diklasifikasikan sebagai berikut :

1. Persediaan barang dagang (merchandise inventory)

Barang yang ada di gudang dibeli oleh pengecer atau perusahaan

perdagangan seperti importer atau eksportir untuk dijual kembali..

Biasanya, barang yang diperoleh untuk dijual kembali secara fisik

tidak diubah oleh perusahaan pembeli.

2. Persediaan manufaktur

Persediaan dari entitas manufaktur, yang terdiri dari:

• Persediaan bahan baku

Barang yang berwujud dibeli atau diperoleh dengan cara lain

(misal, dengan menambang) dan disimpan untuk penggunaan

langsung dalam membuat barang untuk dijual kembali.

• Persediaan barang dalam proses

Barang-barang yang membutuhkan pemrosesan lebih lanjut

sebelum penyelesaian dan penjualan.

• Persediaan barang jadi

Barang-barang manufaktur yang telah diselesaikan dan

disimpan untuk dijual.

• Persediaan cadangan manufaktur

51

Antara lain : minyak pelumas untuk mesin, bahan pembersih

dan bahan lainnya.

3. Persediaan rupa-rupa

Barang-barang seperti perlengkapan kantor, kebersihan, dan

pengiriman. Persediaan jenis ini biasanya digunakan segera dan

biasanya dicatat sebagai beban penjualan atau umum ketika dibeli.

2.2.3 Penjualan

Menurut Mulyadi, penjualan barang dan jasa perusahaan dapat dilaksanakan

melalui penjualan tunai atau penjualan kredit.

1. Penjualan Kredit (Mulyadi, 2001, hal 202)

Dalam transaksi penjualan kredit, jika pesanan dari pelanggan telah

dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka

waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Kegiatan

penjualan kredit ini ditangani oleh perusahaan melalui sistem penjualan

kredit.

Sistem penjualan kredit dilaksanakan oleh perusahaan dengan cara

mengirimkan barang sesuai pesanan yang diterima dari pembeli dan untuk

jangka waktu tertentu perusahaan mempunyai tagihan kepada pembeli

tersebut.

2. Penjualan tunai (Mulyadi, 2001, hal 455-459 )

Penjualan tunai dilaksanakan oleh perusahaan dengan cara

mewajibkan pembeli melakukan pembayaran harga barang terlebih dahulu

sebelum barang diserahkan kepada pembeli. Setelah uang diterima oleh

52

perusahaan, barang kemudian diserahkan kepada pembeli dan transaksi

penjualan tunai kemudian dicatat oleh perusahaan.

Fungsi yang terkait dengan sistem penjualan adalah sebagai berikut :

1. Fungsi Penjualan

Bertanggung jawab menerima surat pesanan dari pelanggan, mengedit

informasi-informasi yang belum lengkap pada surat pesanan tersebut

dan meminta otorisasi kredit.

2. Fungsi Kredit

Bertanggung jawab dalam meneliti status kredit pelanggan dan

memberikan otorisasi pemberian kredit pada pelanggan.

3. Fungsi Gudang

Bertanggung jawab untuk menyimpan dan menyediakan barang yang

dipesan oleh pelanggan dan mengirim barang ke bagian pengiriman

beserta surat julan.

4. Fungsi Pengiriman

Bertanggung jawab membuat dan mengirimkan faktur penjualan

kepada pelanggan serta menyediakan tembusan faktur bagi

kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi.

5. Fungsi penagihan

Bertanggung jawab untuk membuat dan mengirimkan faktur

penjualan kepada pelanggan, serta menyediakan salinan faktur bagi

kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi.

6. Fungsi Akuntansi

53

Bertanggung jawab untuk mencatat piutang yang timbul dari transaksi

penjualan kredit dan mengirimkan pernyataan piutang kepada debitur,

serta membuat laporan penjualan. Di samping itu, fungsi ini juga

bertanggung jawab untuk mencatat harga pokok persediaan yang

dijual ke dalam kartu persediaan.

Menurut Mulyadi (2000, hal 219) sistem dan prosedur yang bersangkutan

dengan sistem penjualan kredit adalah:

a. Prosedur Order Penjualan

Dalam prosedur ini fungsi penjualan menerima pesanan dari pembeli dan

menambahkan informasi penting pada surat order dari pembeli. Fungsi

penjualan kemudian membuat surat order pengiriman dan mengirimkannya

kepada berbagai fungsi yang lain untuk memungkinkan fungsi tersebut

memberikan kontribusi dalam melayani order dari pembeli.

b. Prosedur Persetujuan Kredit

Dalam prosedur ini, fungsi penjualan meminta persetujuan penjualan kredit

kepada pembeli tertentu dari fungsi kredit.

c. Prosedur Pengiriman

Dalam prosedur ini, fungsi pengiriman mengirimkan barang kepada pembeli

sesuai dengan informasi yang tercantum dalam surat order pengiriman yang

diterima dari fungsi pengiriman.

d. Prosedur Penagihan

Dalam prosedur ini, fungsi penagihan membuat faktur penjualan dan

mengirimkannya kepada pembeli. Dalam metode tertentu faktur penjualan

54

dibuat oleh fungsi penjualan sebagai tembusan pada waktu bagian ini

membuat surat order pengiriman.

e. Prosedur pencatatan Piutang

Dalam prosedur ini, fungsi akuntansi mencatat tembusan faktur penjualan ke

dalam kartu piutang atau dalam metode pencatatan tertentu mengarsipkan

dokumen tembusan menurut abjad yang berfungsi sebagai catatan piutang.

f. Prosedur Distribusi Penjualan

Dalam prosedur ini, fungsi akuntansi mendistribusikan data penjualan

menurut informasi yang diperlukan oleh manajemen.

g. Prosedur Pencatatan Harga Pokok Penjualan

Dalam prosedur ini, fungsi akuntansi mencatat secara periodik total harga

pokok produk yang dijual dalam periode akuntansi tertentu.

Menurut Mulyadi (2001, hal 226), transaksi retur penjualan terjadi jika

perusahaan menerima pengembalian barang dari pelanggan. Pengembalian

barang oleh pelanggan harus diotorisasi oleh fungsi penjualan dan diterima oleh

fungsi penerimaan. Fungsi yang terkait dalam melaksanakan transaksi retur

penjualan adalah :

1. Fungsi penjualan

Fungsi ini bertanggung jawab atas penerimaan pemberitahuan mengenai

pengembalian barang yang telah dibeli oleh pembeli. Otorisasi penerimaan

kembali barang yang telah dijual tersebut dilakukan dengan cara membuat

memo kredit yang dikirimkan kepada fungsi penerimaan.

2. Fungsi penerimaan

55

Fungsi ini bertanggung jawab atas penerimaan barang berdasarkan

otorisasi yang terdapat dalam memo kredit yang diterima dari fungsi

penjualan.

3. Fungsi gudang

Fungsi ini bertanggung jawab atas penyimpanan kembali barang yang

diterima dari retur penjualan setelah barang tersebut diperiksa oleh fungsi

penerimaan. Barang yang diterima dari transaksi retur penjualan ini dicatat

oleh fungsi gudang dalam kartu gudang.

4. Fungsi akuntansi

Fungsi ini bertanggung jawab atas pencatatan transaksi retur penjualan ke

dalam jurnal umum dan pencatatan berkurangnya piutang dan

bertambahnya persediaan akibat retur penjualan dalam kartu piutang dan

kartu persediaan. Di samping itu, fungsi ini juga bertanggung jawab untuk

mengirimkan memo kredit kepada pembeli yang bersangkutan.

Menurut Mulyadi (2001, hal 234), jaringan prosedur dalam sistem retur

penjualan adalah sebagai berikut :

1. Prosedur pembuatan memo kredit

Fungsi penjualan membuat memo kredit yang memberikan perintah

kepada fungsi penerimaan untuk menerima barang dari pembeli tersebut

dan kepada fungsi akuntansi untuk pencatatan pengurangan piutang

kepada pembeli yang bersangkutan.

2. Prosedur penerimaan barang

56

Fungsi penerimaan menerima dari pembeli berdasarkan perintah dari

memo kredit yang diterima dari fungsi penjualan. Atas penerimaan barang

tersebut fungsi penerimaan membuat laporan penerimaan barang untuk

melampiri memo kredit yang dikirim ke fungsi akuntansi.

3. Prosedur pencatatan retur penjualan

Dalam prosedur ini transaksi berkurangnya piutang dagang dan

pendapatan penjualan akibat dari transaksi retur penjualan dicatat oleh

fungsi akuntansi ke dalam jurnal umum atau jurnal retur penjualan dan ke

dalam buku pembantu piutang. Dalam prosedur ini pula berkurangnya

harga pokok penjualan dan bertambahnya harga pokok persediaan dicatat

oleh fungsi akuntansi ke dalam jurnal umum dan dalam buku pembantu

persediaan.