2012101028IFBab2001

BAB 2

LANDASAN TEORI

2.1

Pendekatan Basisdata

2.1.1 Pengertian data

Definisi data menurut (Jeffrey, 2005, p5) adalah penyimpanan

representasi objek dan kejadian yang mempunyai arti dan penting di

lingkungan pengguna. Definisi ini termasuk kedalam tipe data yang

terstruktur maupun tidak terstruktur. Tipe data struktur dan yang tidak

terstruktur sering dikombinasikan bersama didalam database

yang sama

untuk menciptakan lingkungan multimedia yang baik.

Data adalah fakta atau observasi tentang transaksi suatu bisnis. Selain itu,

data juga merupakan pengukuran objektif terhadap atribut pada suatu entitas

seperti orang, tempat, benda, dan kejadian (O’Brien,2003, p4).

Dengan demikian dapat disimpulkan bahwa data adalah penyimpanan

representasi objek serta fakta atau observasi tentang transaksi suatu bisnis

selain itu data juga dapat disimpulkan bahwa data adalah adalah fakta

mengenai transaksi bisnis yang dapat disimpan dan digunakan kapan saja

untuk berbagai kepentingan yang akan datang.

2.1.2 Pengertian Basis Data

Sistem basis data juga dapat kita simpulkan sebagai serangkaian program

komputer yang mengendalikan pembuatan, pemeliharaan, dan pemanfaatan

basis data sebagai sebuah organisasi (O’Brien, 2003, p5).

Basis data adalah kumpulan data yang terhubung secara logikal dan juga

deskripsi tentang data ini yang dirancang untuk mendapatkan informasi yang

dibutuhkan suatu organisasi(Connoly, 2005, p15).

Basis data adalah bahasa dan alat-alat grafis untuk mendefinisikan entity-

entity, hubungannya, integrity constraints dan hak otorisasi (Mannino, 2004,

p7).

Basis data adalah kumpulan data yang digunakan oleh sistem aplikasi

tertentu. Sedangkan sistem basis data adalah sistem penyimpanan data yang

terkomputerisasi yang bertujuan untuk menyimpan informasi dan

mengijinkan pengguna untuk mengambil dan mengubah informasi tersebut

sesuai kebutuhan (Date, 2004, p11).

Dengan demikian dapat disimpulkan bahwa basis data adalah

sekumpulan data teratur yang saling terhubung secara logis, disimpan dalam

bentuk yang terstandarisasi, dan dirancang untuk dapat digunakan oleh

banyak pengguna untuk memenuhi kebutuhan informasi.

2.1.3 Database Management System(DBMS)

Database Management System (DBMS) adalah sebuah sistem perangkat

lunak yang memungkinkan pengguna untuk mendefinisikan, membuat,

memelihara, dan juga kontrol akses ke dalam database

(Connoly, 2005,

p16).

DBMS menyediakan fasilitas sebagai berikut:

Data Definition Language

(DDL), memungkinkan pengguna untuk

mendefinisikan basis data, tipe dan strukturnya serta memberikan

batasan pada data untuk disimpan dalam basis data.

Data Manipulation Language (DML), memungkinkan pengguna untuk

menyisipkan data, meng-update data, menghapus data dan menerima

data dari basis data dengan menciptakan fasilitas permintaan data umum

yang disebut query language.

DBMS juga menyediakan kontrol akses ke basis data sebagai berikut:

Security system, dimana mencegah user yang tidak mempunyai hak akses

untuk mengakses basis data.

Integrity system, dimana memelihara konsistensi dari data yang disimpan.

Concurrency control system, dimana memungkinkan untuk berbagi akses

ke basis data.

Recovery control system, dimana dapat mengembalikan database

kondisi semula ketika terjadi kegagalan pada perangkat lunak maupun

perangkat keras.

User-Accessible catalog, dimana mengandung deskripsi data pada basis

data.

2.1.4 Keuntungan DBMS

Menurut Connoly dan Begg (2005, p26) Ada beberapa keuntungan dalam

menggunakan DBMS diantara lain:

Mengontrol Duplikasi Data

DBMS dapat mengurangi duplikasi basis data yang terjadi tetapi tidak

semua duplikasi data dapat dihilangkan, melainkan hanya dapat

dikontrol.

Konsistensi Data

DBMS

menjaga agar data didalamnya tetap konsisten dengan cara

menghilangkan atau mengontrol duplikasi data.

Pengunaan data secara bersama

DBMS

memungkinkan basis data yang dimiliki oleh organisasi bisa

digunakan secara bersama oleh user yang memiliki hak akses.

Meningkatkan integritas data

Integritas basis data mengacu kepada validitas dan konsistensi dari data

yang disimpan. Integritas sendiri biasanya memperdalam arti kata

constraint yang berarti basis data tidak diperbolehkan untuk dilanggar

oleh pemakai basis data itu sendiri.

Meningkatkan keamanan

Keamanan basis data adalah perlindungan basis data dari pengguna yang

tidak memiliki akses.

2.1.5 Kerugian DBMS

Menurut Connoly dan Begg

(2005, p29) Kerugian dalam menggunakan

DBMS diantara lain:

Kompleksitas

Penyediaan fungsi yang kita harapkan dari DBMS

membuat DBMS

menjadi sebuah perangkat lunak yang sangat kompleks. Desainer basis

data, pengembang, admin data dan basis data serta pengguna harus bisa

memahami penuh fungsionalitas DBMS

untuk bisa mendapatkan

keuntungan dari DBMS

ini jika tidak dipahami dengan baik maka

kompleksitas DBMS bisa menjadi kesulitan tersendiri.

Ukuran

Kompleksitas dan juga fungsionalitas membuat DBMS menjadi sebuah

perangkat lunak yang sangat besar ukurannya, sehingga kita harus

memperhitungkan jumlah disk space yang besar serta jumlah memory

yang besar pula agar DBMS ini bisa berjalan dengan efisien.

Harga

Harga DBMS

sendiri tidaklah murah tergantung dari lingkungan dan

juga fungsionalitas yang disediakan oleh DBMS tersebut.

Biaya tambahan perangkat keras

Disk storage yang diperlukan untuk DBMS

dan juga basis data

memungkinkan untuk membeli

storage

tambahan sehingga perlu

disediakan perangkat keras tambahan .

Biaya konversi

Di beberapa keadaan, biaya DBMS serta perangkat keras tambahan tidak

dapat dibandingkan dengan biaya mengkonversi aplikasi agar dapat

berjalan di DBMS baru dan perangkat keras. Biaya ini juga termasuk

biaya untuk melatih pengawai agar dapat mengkonversi dan

menggunakan sistem baru ini.

2.1.6 Database Lifecycle

Menurut Connoly dan Begg (2005, p284), siklus hidup aplikasi basis data

adalah seperti yang ada pada gambar 2.1 di bawah ini:

Gambar 2.1. Database Lifecycle (Connolly dan Begg 2005, p284)

2.1.6.1 Database Planning

Menurut Connolly dan Begg (2005, p285), database

planning

adalah merupakan aktifitas manajemen yang memungkinkan tahapan-

tahapan

dari database

system

development lifecycle direalisasikan

seefisien dan seefektif mungkin.

Database

planning

harus berintegrasi

dengan strategi sistem informasi dalam organisasi. Terdapat tiga hal

pokok yang penting berkaitan dengan strategi sistem informasi, yaitu :

Identifikasi rencana dan sasaran dari enterprise

termasuk mengenai

sistem informasi yang dibutuhkan.

Evaluasi sistem yang ada untuk menetapkan kelebihan dan

kekurangan yang dimiliki

Penilaian kesempatan IT yang mungkin memberikan keuntungan

kompetitif.

Tahapan utama yang paling penting dalam database planning adalah

menentukan mission statement dan mengidentifikasikan mission

objectives. Mission statement untuk mendefinisikan tujuan utama untuk

database project dari aplikasi basis data. Mission statement membantu

menjelaskan kegunaan dari database project dan menyediakan alur yang

lebih jelas untuk mencapai efektifitas dan efisiensi penciptaan dari suatu

aplikasi

basis data yang diinginkan. Kegiatan selanjutnya adalah

mengidentifikasikan mission objectives. Setiap objectives harus

mengidentifikasikan tugas khusus yang harus didukung oleh basis data.

Mission objectives dapat juga disertai dengan beberapa informasi

tambahan yang menspesifikasikan pekerjaan yang harus diselesaikan,

sumber daya yang digunakan dan biaya untuk membayar kesemuanya itu.

Database

planning

harus menyertakan pengembangan standar-standar

yang menentukan bagaimana data dikumpulkan, bagaimana

menspesifikasikan bentuk data, dokumentasi penting apakah yang akan

dibutuhkan dan bagaimana desain dan implementasi harus dilakukan.

2.1.6.2 System Definition

Menurut Connoly dan Begg (2005, p286), system definition

adalah penjelasan mengenai batasan – batasan dan cakupan dari aplikasi

basis data dan sudut pandang user (user view) yang utama. Maksudnya

sebelum memulai untuk merancang aplikasi basis data, hal yang paling

utama untuk dilakukan adalah mengidentifikasikan batasan sistem yang

akan dibangun dan bagaimana sistem tersebut dapat berinteraksi dengan

yang lain dari sistem informasi sebuah organisasi.

User view

mendefinisikan apa yang dibutuhkan dari suatu basis

data yang perspektif, diantaranya aturan kerja khusus dan area aplikasi

enterprise. Mengidentifikasikan user view

sangat penting karena dapat

membantu memastikan bahwa tidak ada user utama didalam suatu basis

data yang terlupakan ketika pembuatan aplikasi baru yang dibutuhkan.

2.1.6.3 Requirement Collection and Analysis

Menurut Connolly dan Begg (2005, p288), requirement collection and

analysis adalah suatu proses pengumpulan dan analisis

informasi

mengenai bagian organisasi yang didukung oleh sistem

basis data, dan

menggunakan informasi tersebut untuk mengidentifikasi kebutuhan untuk

sistem yang baru. Informasi dikumpulkan untuk setiap user view

utama

yang meliputi deskripsi data yang digunakan atau

dihasilkan, detail

mengenai bagaimana data digunakan atau dihasilkan dan beberapa

kebutuhan tambahan untuk aplikasi basis data yang baru.

Terdapat tiga pendekatan untuk menentukan bagaimana mengatur

aplikasi basis data dengan multiple user view yaitu:

Pendekatan Terpusat

Kebutuhan untuk setiap user view digabungkan menjadi sekumpulan

kebutuhan

Pendekatan Integrasi View

Kebutuhan untuk setiap user view yang digunakan untuk membangun

model data terpisah untuk merepresentasikan user view

tersebut.

Hasil dari

model data tersebut nantinya akan digabungkan dalam

tahapan desain basis data.

Kombinasi dari terpusat dan integrasi view

2.1.6.4 Database Design

Menurut Connolly dan Begg (2005, p291), database

design

merupakan suatu proses pembuatan sebuah desain basis data yang

mendukung

misi perusahaan dan misi objektif untuk kebutuhan sistem

basis data. Terdapat 4 pendekatan dalam desain basis data :

Top Down

Pendekatan ini diawali dengan pembentukan model data yang berisi

beberapa entitas high level

dan relationship. Yang kemudian

menggunakan pendekatan top-down

secara berturut-turut untuk

mengidentifikasikan entitas lower level, relationship

dan atribut

lainnya.

Bottom Up

Pendekatan ini dimulai dari atribut dasar (sifat-sifat entitas dan

relationship), dengan analisis dari penggabungan antar atribut, yang

dikelompokan kedalam suatu relasi yang mempresentasikan tipe dari

entitas dan relationship antar entitas.

Inside Out

Pendekatan ini berhubungan dengan pendekatan bottom up

tetapi

sedikit berbeda dengan identifikasi awal entitas utama dan kemudian

menyebar ke entitas, relationship, dan atribut terkait lainnya yang

lebih dahulu diidentifikasikan.

Mixed Strategy

Pendekatan yang menggunakan pendekatan bottom up dan top down

untuk bagian yang berbeda sebelum pada akhirnya digabungkan.

Tiga fase desain basis data menurut Connolly dan Begg (2005, p293),

tahapan-tahapan dalam desain basis data:

Perancangan Basis data Konseptual (Conceptual Database Design)

Menurut Connolly dan Begg (2005, p293), perancangan basis data

konseptual merupakan suatu proses pembentukan model dari

informasi yang digunakan dalam perusahaan, independen dari

keseluruhan aspek fisik. Model data dibangun dengan menggunakan

informasi dalam spesifikasi kebutuhan pengguna. Model data

konseptual merupakan sumber informasi untuk fase desain logikal.

Perancangan Basis data Logikal (Logical Database Design)

Menurut Connolly dan Begg (2005, p294), perancangan basis data

logikal merupakan suatu proses pembentukan model dari informasi

yang digunakan dalam perusahaan berdasarkan model data tertentu,

tetapi independen terhadap DBMS tertentu dan aspek fisik lainnya.

Model data konseptual yang telah dibuat sebelumnya, diperbaiki dan

dipetakan kedalam model data logikal.

Perancangan Basis data Fisikal (Physical Database Design)

Menurut Connolly dan Begg (2005, p294), perancangan basis data

fisikal merupakan suatu proses yang menghasilkan deskripsi

implementasi basis data pada penyimpanan sekunder.

Menggambarkan struktur penyimpanan dan metode akses yang

digunakan untuk mencapai akses yang efisien terhadap data.

2.1.6.5 Database Management System Selection

Menurut Connolly dan Begg (2005, p295), Database

Management

System Selection adalah pemilihan DBMS

yang tepat untuk mendukung

aplikasi basis data. Tahapan-tahapan utama dalam memilih DBMS:

Mendefinisikan terminologi dari studi referensi

Mendaftar 2 atau 3 produk

Evaluasi produk

Rekomendasi pilihan dan juga laporan produk

2.1.6.6 Application Design

Menurut Connolly dan Begg (2005, p299),

Application Design

adalah rancangan dari user interface

dan aplikasi program yang

digunakan dan proses dari sistem basis data.

2.1.6.7 Prototyping (Optional)

Menurut Connolly dan Begg (2005, p304),

Prototyping

dalah

membangun model kerja suatu aplikasi basis data. Tujuan utama dari

pembuatan prototyping adalah :

Identifikasi fitur-fitur dari sistem yang berjalan dengan baik atau

tidak.

Memberikan perbaikan-perbaikan atau penambahan fitur baru.

Klarifikasi kebutuhan user.

Evaluasi kemungkinan yang akan terjadi dari desain sistem khusus.

Terdapat dua macam strategi prototyping yang digunakan saat ini yaitu :

1. Requiment prototyping

Menggunakan prototype

untuk menentukan kebutuhan dari aplikasi

basis data yang diinginkan dan ketika kebutuhan itu terpenuhi

prototype akan dibuang.

2. Evolutionary prototyping

Digunakan untuk tujuan yang sama. Perbedaannya, prototype

tidak

dibuang tetapi dengan pembembangan lanjutan menjadi aplikasi basis

data yang digunakan.

2.1.6.8 Implementation

Menurut Connolly dan Begg (2005, p304), implementation

merupakan realisasi fisik dari basis data dan desain aplikasi.

Implementasi basis data dapat dicapai dengan menggunakan Data

Definition Language

(DDL) untuk membuat skema basis data dan file

basis data kosong, DDL untuk membuat user view yang diinginkan, 3GL

dan 4GL untuk membuat program aplikasi. Termasuk transaksi basis data

disertakan dengan menggunakan DML,

atau ditambahkan pada bahasa

pemrograman.

2.1.6.9 Data Convertion and Loading

Menurut Connolly dan Begg (2005, p305), Data convertion and

loading merupakan pemindahan data yang ada kedalam basis data baru

dan mengkonversikan aplikasi yang ada agar dapat digunakan pada basis

data yang baru. Tahapan ini dibutuhkan ketika sistem basis data baru

menggantikan sistem yang lama. DBMS biasanya memiliki utilitas yang

memanggil ulang file yang sudah ada kedalam basis data baru, dapat juga

mengkonversi dan menggunakan program aplikasi dari sistem yang lama

untuk digunakan oleh sistem yang baru.

2.1.6.10 Testing

Menurut Connolly dan Begg (2005, p305), testing merupakan suatu

proses eksekusi program aplikasi dengan tujuan untuk menemukan

kesalahan. Dengan menggunakan strategi tes yang direncanakan dan data

yang sesungguhnya. Pengujian hanya akan terlihat jika terjadi kesalahan

software. Mendemonstrasikan basis data

dan program aplikasi terlihat

berjalan seperti yang diharapkan.

2.1.6.11 Operational Maintenance

Menurut Connolly dan Begg(2005, p306), Operational maintenance

merupakan suatu proses pengawasan dan pemeliharaan sistem setelah

instalasi, meliputi:

Pengawasan performa sistem, jika performa menurun maka

menentukan perbaikan atau pengaturan ulang jadwal.

Pemeliharaan aplikasi basis data jika dibutuhkan

Penggabungan kebutuhan baru kedalam aplikasi basis data

2.1.7 Entitiy Relationship Modelling

2.1.7.1 Tipe Entitas

Menurut Connolly dan Begg (2005, p343), tipe entitas adalah

kumpulan dari objek-objek dengan sifat atau property yang sama, yang di

identifikasi oleh

enterprise mempunyai eksistensi yang independent.

Keberadaannya dapat berupa fisik maupun abstrak.

Representasi diagram dari tipe entitas:

Gambar 2.2 Representasi diagramatik dari tipe entitas staff dan branch

Entity occurrence adalah pengidentifikasian objek yang unik dari sebuah

tipe entitas. Setiap entitas di identifikasikan dan disertakan property-nya.

2.1.7.2 Relationship Type

Menurut Connolly dan Begg(2005, p346), relationship type adalah

kumpulan keterhubungan yang mempunyai arti antara tipe entitas yang

ada. Relationship occurrence

adalah keterhubungan yang diidentifikasi

secara unik yang meliputi keberadaan tiap tipe entitas yang berpartisipasi.

Entity Name

Staff

Branch

Relationship Name

Has

Gambar 2.3 Representasi Relationship Tipe Branch Memiliki Staff

Menurut Connolly dan Begg (2005, p347), derajat relationship

adalah jumlah entitas yang berpartisipasi dalam suatu relationship.

Derajat relationship terdiri dari :

Binary relationship adalah keterhubungan antar dua tipe entitas. Contoh

hubungan binary relationship adalah hubungan has pada gambar dibawah

ini:

Has

‘Branch Has Staff’

Gambar 2.4 Representasi Relationship Tipe Branch Memiliki Staff

Ternary relationship adalah keterhubungan antar tiga tipe entitas.

Staff

Branch

Relationship Name

Branch

Staff

contoh dari ternary relationship adalah register

dengan tiga tipe

entitas.

Quarternary relationship adalah keterhubungan antar empat tipe

entitas.

Unary relationship adalah keterhubungan antar tipe entitas, dimana

tipe entitas tersebut berpartisipasi lebih dari satu kali dengan peran

yang berbeda. Kadang disebut juga recursive relations.

2.1.7.3 Attribute

Menurut Connolly dan Begg (2005, p350), Attribute adalah sifat-sifat

dari sebuah entity atau type relationship.

Domain Attribute adalah himpunan nilai yang diperbolehkan untuk satu

atau lebih atribut.

Menurut Connolly dan Begg (2005, p351), jenis-jenis atribut antara lain:

Simple Attribute

adalah atribut yang terdiri dari satu komponen

tunggal dengan keberadaan yang independent dan tidak dapat dibagi

menjadi bagian yang lebih kecil lagi. Dikenal juga dengan nama

Atomic Attribute.

Composite Attribute adalah atribut yang terdiri dari berbagai

komponen, dimana masing – masing komponen memiliki keberadaan

yang independent. Misalkan atribut Address dapat terdiri dari Street,

City, PostCode.

Single –

valued Attribute

adalah atribut yang mempunyai nilai

tunggal untuk setiap kejadian. Misalkan entitas Branch memiliki satu

nilai untuk atribut branchNo pada setiap kejadian.

Multi-valued Attribute adalah atribut yang mempunyai beberapa

nilai untuk setiap kejadian. Misalkan entitas Branch

memiliki

beberapa nilai untuk atribut telpNo pada setiap kejadian.

Derived Attribute

adalah atribut yang memiliki nilai yang

dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus

berasal dari satu entitas.

Menurut Connolly dan Begg (2005, p352), macam-macam tipe keys

yaitu:

Candidate Key

adalah jumlah minimal atribut-atribut yang dapat

mengidentifikasikan setiap kejadian / record secara unik.

Primary Key adalah candidate key

yang dipilih untuk meng-

identifikasikan setiap kejadian / record dari suatu entitas secara unik.

Composite Key adalah candidate key yang terdiri dari dua atau lebih

atribut.

Foreign Key adalah atribut sebuah tabel yang menggabungkan diri ke

tabel lain.

2.1.7.4 Strong and Weak Entity Type

Menurut Connolly dan Begg (2005, p354), entitas Strong dan Weak

Type adalah entitas yang keberadaannya tidak bergantung pada entitas

lain, sedangkan Weak Type Entitas adalah entitas yang keberadaannya

bergantung pada entitas lain. Strong Type Entitas terkadang disebut

dengan parent, owner dominant

dan Weak Type

Entitas disebut child,

dependent, subordinate.

2.1.7.5 Structural Constraint

Menurut Connolly (2005, p356), batasan utama pada

relationship

disebut multiplicity.

Multiplicity adalah jumlah kemungkinan dari

kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu

kejadian dari entitas lain yang berhubungan melalui suatu relationship.

Hubungan binary secara umum dibedakan menjadi:

One-to-one (1:1) Relationships

Gambar 2.5 One-to-one Relaltionships

Pada gambar dapat dilihat bahwa A hanya terhubung one-to-one (1 : 1)

dengan C, dan B hanya terhubung one-to-one (1 : 1) dengan D. Jadi dari

gambar tersebut dapat dituliskan notasi multiplicity-nya dengan gambar di

bawah ini.

Gambar 2.6 Notasi One-to-one Relationships

One-to-many (1:*) Relationships

Gambar 2.7 One-to-many Relationships

Pada gambar dapat dilihat bahwa B terhubung one-to-many (1 : *) dengan

D dan E. Jadi dari gambar tersebut dapat dituliskan notasi multiplicity-nya

dengan gambar di bawah ini.

Gambar 2.8 Notasi one-to-many Relationships

many-to-many (*:*) Relationships

Gambar 2.9 Many-to-many Relationships

Pada gambar, dapat dilihat bahwa A terhubung one-to-many (1 : *)

dengan A dan B. Jadi dari entitas Group 1 (value-nya A dari gambar di atas)

dan Group 2 (value-nya E dari gambar di atas) terhubung many-to-many (* :

*). Dari gambar tersebut dapat dituliskan notasi multiplicity-nya dengan

gambar di bawah ini.

Gambar 2.10 Notasi many-to-many Relationships

2.1.8 Normalisasi

2.1.8.1 Pengertian Normalisasi

Menurut Connolly dan Begg (2005, p388), “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 untuk menghasilkan sekumpulan relasi

dengan sifat –

sifat yang diinginkan, untuk memenuhi kebutuhan data

pada perusahaan.

2.1.8.2 Tahap – tahap Normalisasi

Tahap – tahap Normalisasi yang biasa digunakan terdiri dari:

Unnormalized Form (UNF)

Menurut Connolly dan Begg (2005, hal 402), suatu tabel yang

berisikan satu atau lebih grup/data yang berulang.

First Normal Form (1NF)

Menurut Connolly dan Begg (2005, p403), sebuah relasi dimana

setiap irisan antara baris dan kolom berisikan satu dan hanya satu

nilai.

Second Normal Form (2NF)

Menurut Connolly dan Begg (2005, p407), suatu relasi yang ada

dalam 1NF dan setiap atribut bukan primary key bergantung penuh

secara fungsional pada primary key.

Third Normal Form(3NF)

Menurut Connolly dan Begg

(2005, p409), suatu relasi yang ada

dalam 1NF dan 2NF dan atribut bukan non-primary key bergantung

secara transitif pada primary key.

2.1.9 Metodologi Perancangan Sistem Basis Data

2.1.9.1 Perancangan Sistem Basis Data Konseptual

Menurut Connolly dan Begg (2005, p439), perancangan sistem basis

data konseptual adalah suatu proses pembentukan model dari informasi

yang digunakan dalam perusahaan, independent dari semua aspek fisik.

Menurut Connolly dan Begg (2005, p442), langkah –

langkah yang

digunakan antara lain:

Langkah 1 : Membangun model data konseptual lokal untuk masing-

masing view

Tahap 1.1 Mengidentifikasi tipe – tipe entitas

Tujuan : untuk mengidentifikasikan tipe entitas utama yang akan

dibangun.

Langkah pertama dalam membangun model data konseptual lokal

mengidentifikasi objek pertama user. Objek ini adalah tipe entitas untuk

model tersebut. Salah satu metode untuk mengidentifikasikan entitas

adalah dengan memeriksa spesifikasi kebutuhan user. Dari spesifikasi ini,

kita mengidentifikasi kata benda. Contoh tipe entitas: StaffNumber,

StaffName, PropertyNumber, PropertyAddress, Rent, NumberOfRoom.

Sesudah tipe –

tipe entitas diidentifikasi, pemberian nama untuk tiap

entitas harus jelas. Nama dan deskripsi entitas sebaiknya disimpan dalam

kamus data. Jika sebuah entitas dikenal dengan nama lain yang disebut

sinonim atau alias maka disimpan pada kamus data.

Tahap 1.2 Identifikasi tipe relationship(relasi)

Tujuan: untuk mengidentifikasi

relationship

yang penting terdapat

diantara tipe entitas yang telah diidentifikasi.

Salah satu metode yang digunakan untuk mengidentifikasi tipe relasi,

yaitu dengan cara mencari kata benda didalam spesifikasi kebutuhan user.

Contoh : Staff Manage PropertyForRent, PrivateOwner, PrivateOwner

Owns PropertyForRent AssociatedWith Lease.

Tahap 1.3 Identifikasi tipe dan menggabungkan attribute dengan

entitas atau tipe relasi

Tujuan : untuk mengasosiasikan atribut yang sesuai dengan entitas atau

tipe relasi.

Metode yang digunakan mirip dengan identifikasi tipe entitas yaitu

dengan dengan mencari kata benda dalam spesifikasi kebutuhan user.

Menurut Connoly dan Begg (2005, p339), terdapat 3 jenis atribut:

Simple Attribute

Simple Attribute adalah atribut yang terdiri dari satu komponen tunggal

dengan keberadaan yang independent

dan tidak dapat dibagi menjadi

bagian yang lebih kecil lagi. Dikenal juga dengan nama Atomic Attribute

Composite Attribute adalah yang terdiri dari beberapa komponen, dimana

masing –

masing komponen memiliki keberadaan yang independen.

Misalkan atribut Address dapat terdiri dari Street, City, PostCode.

Single atau multivalue attributes

Single-valued Attribute adalah atribut yang mempunyai nilai tunggal

untuk setiap kejadian. Misalkan entitas Branch memiliki satu nilai untuk

atribut branchNo pada setiap kejadian.

Multi-valued Attribute adalah atribut yang mempunyai beberapa nilai

untuk setiap kejadian. Misalkan entitas Branch memiliki beberapa nilai

untuk atribut telpNo pada setiap kejadian.

Derived attribute

Derived Attribute adalah atribut yang memiliki nilai yang dihasilkan dari

satu atau beberapa atribut lainnya, dan tidak harus berasal

dari satu

entitas.

Tahap 1.4 Menentukan domain attribute

Tujuan : untuk menentukan domain atribut pada model data konseptual.

Domain Attribute adalah himpunan nilai yang diperbolehkan untuk satu

atau lebih atribut. Contoh: domain atribut dari nomor staff (staffNo)

memiliki panjang karakter 5, dengan 2 karakter pertama berupa huruf dan

3 karakter selanjutnya berupa angka antara

1 -999 . Model data yang baik menspesifikasikan domain untuk setiap

atribut meliputi kumpulan nilai untuk setiap atribut dan ukuran beserta

format atribut.

Tahap 1.5 Menentukan atribut candidate dan primary key

Tujuan : untuk mengidentifikasi candidate key pada masing – masing tipe

entitas dan, jika terdapat lebiih dari satu candidate key, pilih salah satu

untuk dijadikan primary key.

Candidate Key adalah jumlah minimal atribut-atribut yang dapat

mengidentifikasikan setiap kejadian atau record secara unik.

Primary Key adalah candidate key

yang dipilih untuk meng-

identifikasikan setiap kejadian atau record dari suatu entitas secara unik.

Composite Key adalah candidate key yang terdiri dari dua atau lebih

atribut.Foreign key adalah atribut sebuah tabel yang menggabungkan diri

ke tabel lain.

Tahap 1.6 Mempertimbangkan konsep pemodelan echanced (optional

step)

Tujuan : untuk mempertimbangkan penggunaan konsep pemodelan

enhanced , seperti/generalisasi, agregasi dan komposisi.

Pada pendekatan spesialisasi, harus memperhatikan perbedaan antara

entitas dengan mendefinisikan satu atau lebih subclass dari sebuah entitas

superclass. Jika memilih pendekatan generalisasi, diusahakan untuk

mengidentifikasi fitur-fitur umum antar entitas untuk mendefinisikan

sebuah entitas superclass generalisasi. Pendekatan agregasi digunakan

untuk menghadirkan hubungan “mempunyai - sesuatu” atau “bagian dari

“ relasi antara tipe entitas, dimana yang satu menghadirkan “keseluruhan”

dan yang lainnya sebagai “bagian nya”. Komposisi menghadirkan

hubungan diantara tipe entitas dimana terdapat kepemilikan yang kuat

keterhubungan antara “keseluruhan” dan bagiannya”.

Tahap 1.7 Cek model dari redundancy

Tujuan : untuk memeriksa adanya redudansi pada model.

Terdapat dua aktifitas dalam tahapan ini :

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

Pada saat mengidentifikasi entitas, mungkin akan teridentifikasi 2 entitas

yang mempresentasikan objek yang sama pada perusahaan. Untuk

kejadian ini, kedua entitas harus digabung jika primary key berbeda, pilih

salah satu primary key tersebut dan biarkan yang ain sebagai alternate

key.

Menghilangkan relasi yang redudansi

Suatu relasi dikatakan redudansi jika informasi yang sama dapat

diperbolehkan melalui relasi yang lain.

Tahap 1.8 Validasi model konseptual lokal terhadap transaksi user

Tujuan : untuk memastikan bahwa model konseptual lokal mendukung

kebutuhan transaksi yang dibutuhkan oleh view :

Dua pendekatan yang mungkin dilakukan untuk memastikan bahwa

model data konseptual mendukung transaksi yang dibutuhkan :

Mendeskripsikan transaksi

Memeriksa apakah semua informasi (entitas, relasi dan atributnya) yang

dibutuhkan oleh

setiap transaksi telah disediakan oleh model, dengan

mendokumentasikan sebuah deskripsi dari kebutuhan transaksi.

Memakai jalur transaksi

Memvalidasi model data terhadap transaksi yang dibutuhkan yang

melibatkan diagram yang menghadirkan jalur setiap transaksi dalam

ERD.

Tahap 1.9 Review model konseptual data lokal terhadap need user

Tujuan : untuk meninjau kembali model data konseptual lokal dengan

user untuk memastikan model yang dihadirkan sesuai.

Pada tahap ini, data konseptual lokal akan ditinjau ulang oleh user. Model

data konseptual meliputi ERD

dan dokumentasi pendukung yang

menggambarkan model data tersebut. Jika terjadi anomali pada model

data, maka harus dilakukan perubahan yang mungkin memerlukan

pengulangan tahapan-tahapan sebelumnya. Proses ini terus berulang

sampai model data benar-benar menjadi representasi aktual dari

perusahaan.

2.1.9.2 Perancangan Sistem Basis Data Logikal

Menurut Connolly dan Begg (2005, p439), perancangan sistem basis

data logikal adalah proses pembangunan model informasi yang digunakan

pada sebuah perusahaan berdasarkan model data spesifik, tetapi tidak

tergantung pada database management system dan pertimbangan fisikal

lainnya.

Menurut Connolly dan Begg (2005, p462), langkah-langkah yang

digunakan antara lain :

Langkah 2 Membangun dan memvalidasi model data logikal lokal

untuk masing-masing view

Tujuan : untuk membangun model data logikal lokal dari model data

konseptual lokal yang menghadirkan view

tertentu dari perusahaan dan

memvalidasikan model ini untuk menjamin agar strukturnya benar

(menggunakan teknik normalisasi)

dan menjamin dalam mendukung

transaksi yang dibutuhkan.

Tahap 2.1 Menentukan relasi untuk model data logikal

Tujuan : membuat relasi untuk data logikal yang dapat menghadirkan

entitas, relasi, dan hubungan yang telah teridentifikasi.

Pembagian relasi dari sebuah model data diantaranya :

Tipe entitas kuat (Strong Entity)

Pada setiap entitas kuat pada model data, buat sebuah relasi yang

memasukkan semua simple atribute dari entitas tersebut. Untuk

composite attribute, seperti name, dimasukkan hanya bagian penting

dari simple attribute, dinamakan fName dan lName dalam relasi.

Contoh : Staff(StaffNo, fName, lName, Posisition, Sex, DOB)

Primary Key (StaffNo).

Tipe entitas lemah (Weak Entity)

Pada setiap entitas lemah pada model data, buat sebuah relasi yang

memasukkan semua simple attribute dari entitas. Primary key

dari

entitas lemah partially

atau sepenuhnya diturunkan dari setiap

pemilik entitas dan identifikasi dari primary key pada entitas lemah

tidak dapat dibuat sampai seluruh relasi dengan pemilik entitas telah

ditetapkan.

Contoh : Preference(PrefType, MaxRent) Primary key

None (at

present).

Pada situasi ini,

primary key

untuk relasi preference

tidak dapat

diidentifikasi sampai hubungan states telah dipetakan.

Tipe relasi binary one-to-many (1 : *)

Pada setiap hubungan binary 1 : *, entitas pada “one side” dari

hubungan relasi dirancang sebagai parent entity

dan entitas pada

“many side” dirancang sebagai child entity.

Tipe relasi one-to-one (1 : 1)

Membuat hubungan untuk merepesentasikan relasi 1 : 1 sedikit lebih

rumit sebagai

cardinality

tidak dapat digunakan untuk

mengindentifikasi relasi entitas parent dan child.

Tiper relasi recursive one-to-one (1 : 1)

Relasi recursive 1 : 1, aturan untuk partisipasi sebagai penggambaran

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

Tipe relasi superclass atau subclass

Pada setiap relasi superclass

atau subclass

pada model data

konseptual, kita mengindentifikasi entitas superclass sebagai parent

entity dan entitas subclass sebagai child entity.

Tipe relasi binary many-to-many (* : *)

Pada setiap relasi binary * : *, buat sebuah hubungan untuk

menghadirkan relasi dan menyertakan atribut apa saja yang termasuk

dalam bagian dari relasi.

Tipe relasi kompleks

Pada setiap relasi kompleks, buat sebuah hubungan yang

menghadirkan relasi dan sertakan beberapa atribut yang merupakan

bagian dari relasi.

Atribut multi valued

Pada setiap atribut multi valued dalam entitas, buat relasi baru untuk

menghadirkan atribut multi valued dan sertakan juga primary key

dari entitas untuk relasi baru dan bertindak sebagai foreign key.

Tahap 2.2 Validasi hubungan menggunakan normalisasi

Tujuan : untuk memvalidasikan hubungan pada model data logik

lokal

menggunakan teknik normalisasi.

Proses normalisasi terdiri dari :

First normal form (1NF)

Menghilangkan kelompok yang berulang.

Second normal form (2NF)

Menghilangkan ketergantungan parsial pada primary key.

Third normal form (3NF)

Menghilangkan ketergantungan transitif pada primary key.

Boyce codd normal form (BCNF)

Menghilangkan anomali dari ketergantungan fungsional.

Tahap 2.3 Validasikan hubungan terhadap transaksi user

Tujuan : untuk memastikan hubungan pada model data logikal yang

mendukung kebutuhan transaksi oleh view.

Pada tahap 1.8 memastikan bahwa model data konseptual lokal

mendukung kebutuhan transaksi. Pada tahap ini, dilakukan pengecekkan

relasi yang dibuat pada langkah sebelumnya mendukung transaksi

tersebut dan memastikan tidak terdapat error yang telah diketahui ketika

membuat hubungan.

Tahap 2.4 Menetapkan batasan integritas

Tujuan : untuk menetapkan batasan integritas yang telah diberikan pada

view.

Batasan integritas adalah batasaan yang telah ditentukan untuk

melindungi basis data dari ketidakkonsistenan.

Lima tipe dari batasan integritas yang harus diperhatikan :

Data yang dibutuhkan

Beberapa atribut harus memilki sebuah nilai yang valid (tidak

mengandung null).

Contoh : setiap anggota staff harus memiliki jabatan.

Batasan domain atribut

Setiap atribut memilki sebuah domain (sekumpulan nilai harus sah).

Contoh : jenis kelamin dari anggota staff dapat “M” atau “F”, jadi

domain dari atribut jenis kelamin adalah karakter tunggal. Batasaan

ini harus diidentifikasi dalam kamus data.

Integritas entitas

Primary key dari entitas tidak boleh null.

Contoh : setiap baris dari relasi staff

harus memiliki nilai untuk

atribut primary key.

Integritas referensial

Sebuah foreign

key

menghubungkan setiap baris pada relasi child

kedalam relasi parent dengan menyamakan nilai dari candidate key.

Batasan perusahaan

Perhatikan batasan perusahaan yang dikenal sebagai peraturan bisnis.

Tahap 2.5 Meninjau kembali model data logikal lokal dengan user

Tujuan : untuk memastikan bahwa model data logikal lokal dan

dokumentasi pendukung yang menggambarkan model yang sesuai dengan

model data logikal lokal pada

view

harus diselesaikan dan

didokumentasikan. Untuk menyelesaikan tahapan ini, dilakukan

peninjauan model logikal dan dukungan dokumentasi dengan user.

Tahap 2.6 Menggabungkan model data logikal kedalam model global

Tujuan : untuk menggabungkan model data logikal lokal kedalam single

model data logikal global yang menghadirkan semua user view dari basis

data.

Tahap 2.6.1 Menggabungkan model data logikal lokal kedalam

single model data logikal global

Tujuan : untuk

menggabungkan model data logikal lokal kedalam

single model data logikal global.

Review

nama-nama dan isi dari entitas dan relasi dan candidate

keys nya. Masalah dapat muncul ketika dua atau lebih entitas :

Memiliki nama yang sama tetapi pada kenyataannya

berbeda

(homonim).

Sama tetapi berbeda namanya(sinonim).

Review nama-nama dan isi dari relasi atau foreign keys.

Menggabungkan entitas atau relasi dari model data lokal.

Aktifitas khusus yang terlibat dalam tugas ini antara lain :

Menggabungkan entitas atau relasi dengan nama yang sama dan

primary key yang sama.

Menggabungkan entitas atau relasi dengan nama yang sama tetapi

primary key nya berbeda.

Menggabungkan entitas atau relasi dengan nama yang berbeda

menggunakan primary key yang sama tau berbeda.

Memasukkan (tanpa menggabungkan) entitas atau relasi unik pada

tiap-tiap model data lokal.

Menggabungkan relasi atau foreign keys dari model data lokal.

Aktifitas pada langkah ini antara lain :

Menggabungkan relasi atau foreign keys dengan nama yang sama

dan tujuan yang sama.

Menggabungkan relasi atau foreign

keys

dengan nama yang

berbeda tetapi tujuan yang sama .

Memasukkan (tanpa menaggabungkan) relasi atau foreign

keys

unik pada setiap model data logikal.

Memeriksa entitas yang hilang dan relasi atau foreign keys.

Memeriksa foreign keys.

Memeriksa batasan integritas.

10.

Menggambar global ER/ diagram relasi.

11.

Update dokumentasi.

Tahap 2.6.2 Memvalidasikan model data logikal global

Tujuan : untuk memvalidasikan relasi yang dibuat dari model data

logikal global menggunakan teknik normalisasi dan memastikan

dukungan terhadap kebutuhan transaksi.

Tahap 2.6.3 Review model data logikal global dengan user view

Tujuan : untuk mereview model data logikal global dengan pengguna

untuk memastikan bahwa mereka menanggap model untuk menjadi

representasi sejati dari kebutuhan darta dari perusahaan.

Tahap 2.7 Memeriksa pertumbuhan masa depan

Tujuan : untuk menentukan apakah terdapat perubahan yang nyata dimasa

depan dan menilai apakah model data logikal dapat mengakomodasi

perubahan ini.

2.1.9.3 Perancangan Sistem Basis Data Fisikal

Menurut Connolly dan begg (2005, p296), Perancangan Sistem Basis

Data Fisikal adalah suatu proses yang menghasilkan deskripsi

implementasi basis data pada pemyimpanan sekunder. Menggambarkan

struktur pemyimpanan dan metode akses yang digunakan mencapai akses

efisien terhadap data. Dapat dikatakan juga desain fisikal merupakan cara

pembuatan menuju sistem DBMS tertentu.

Menurut Connolly dan begg (2005, p497), langkah-langkah yang

digunakan antara lain :

Langkah 3 Terjemahkan model data logikal global untuk target

DBMS

Tujuan : untuk menghasilkan skema basis data relasional dari model data

logikal yang dapat diimplementasikan pada sasaran DBMS.

Tahap 3. 1 Merancang relasi dasar

Tujuan : untuk memutuskan bagaimana menghadirkan identifikasi relasi

dasar dalam model data logikal kedalam sasaran DBMS.

Pada masing-masing identifikasi relasi pada model data logikal,

definisinya terdiri dari :

Nama relasi.

Daftar kurung simple attribute.

Primary key dan, yang sesuai dengan alternate keys dan foreign keys.

Batasan integritas referensial untuk beberapa identifikasi foreign

keys.

Dari kamus dara, masing-masing atribut antara lain :

Domainnya, terdiri dari tipe data, panjang dan beberapa batasan

domain.

Sebuah nilai default opsional untuk atribut.

Apakah atribut dapat bernilai null.

Apakah atribut dihasilkan dan jika demikian bagaimana cara

mengkomputasinya.

Tahap 3.2 Merancang representasi dari data yang dihasilkan

Tujuan : untuk memutuskan bagaimana unbtuk mewakili data yang

diperoleh dalam model data logikal dalam target DBMS.

Tahap 3.3 Merancang batasan-batasan perusahaan

Tujuan : untuk merancang batasan-batasan umum untuk sasaran DBMS.

Langkah 4 Desain organisasi file dan indeks-indeks

Tujuan : untuk menghasilkan skema basis data relasional dari model data

logikal yang dapat diimplementasikan pada sasaran DBMS.

Tahap 4.1 Analisa transaksi-transaksi

Tujuan : untuk memahami fungsi dari transaksi-transaksi yang akan

dijalankan pada basis data dan untuk menganalisis transaksi-transaksi

yang penting.

Untuk melakukan

desain basis data fisikal secara efektif, harus

memiliki pengetahuan mengenai transaksi atau query

yang akan

berjalan pada basis data. Ini mencakup baik informasi kualitatif

maupun kuantitatif. Dalam menganalisis transaksi, kita mencoba untuk

mengidentifikasi kinerja, sseperti :

Transaksi yang sering berjalan dan memiliki dampak signifikan

pada suatu kinerja.

Transaksi yang sangat penting dalam operasi bisnis.

Sealama perhari/minggu ketika akan ada permintaan tinggi yang

dibuat pada basis data(disebut belum puncak).

Tahap 4.2 Pilih organisasi file

Tujuan : untuk menentukan organisasi file

yang efisien untuk setiap

relasi dasar.

Adapun tipe organisasi file :

Heap.

Hash.

Indexed Sequential Offiece Access Method (ISAM)

B*-tree.

Clusters.

Tahap 4.3 Pilihan indeks-indeks

Tujuan : untuk memutuskan bagaimana menghadirkan identifikasi

relasi dasar dalam model data logikal kedalam sasaran DBMS.

Salah satu pendekatan untuk memilih organisasi file yang sesuai

untuk relasi adalah untuk menjaga tupel yang tidak terurut dan

membuat sebagai indeks sekunder yang diperlukan. Pendekatan lain

adalah uturan tuple dalam relasi dengan menentukan indeks utama atau

clustering. Dalam hal ini, pilih atribut untuk mengatur atau clustering

tupel sebagai :

Atribut yang paling sering digunakan untuk bergabung dengan

operasi, karena hal ini membuat operasi bergabung lebih efisien.

Atribut yang digunakan paling sering untuk mengakses tuple

dalam suatu relasi dalam urutan yang atribut.

Jika mengatur atribut yang dipilih adalah sebagai kunci

daru relasi,

indeks akan menjadi indeks utama; jika mengatur atribut bukan

sebagai kunci, indeks akan menjadi indeks clustering. Ingat bahwa

setiap relasi hanya dapat memiliki sebuah indeks utama atau indeks

clustering.

Tahap 4.4 Perkirakan kebutuhan tempat penyimpanan

Tujuan : untuk memperkirakan jumlah tempat penyimpanan yang akan

dibutuhkan oleh basis data.

Langkah 5 Merancang user view

Tujuan : untuk merancang

user view

yang diidentifikasikan selama

pengumpulan kebutuhan dan analisis pada tahap Database

System

Development Lifecycle.

Langkah 6 Merancang mekanisme keamanan

Tujuan : untuk merancang mekanisme keamanan untuk basis data

sebagaimana ditentukan oleh user

selama pengumpulan kebutuhan dan

analsisis pada tahap Database System Development Lifecycle.

Pada DBMS

relasional umumnya memberikan dua jenis keamanan

database yaitu:

Sistem keamanan

Sistem keamanan meliputi akses dan penggunaan basis data pada

tingkat sistem, seperti nama pengguna dan password

Keamanan data

Keamanan data meliputi akses dan penggunaan objek basis data

(seperti sebagai relasi dan view) dan tindakan

user dapat memiliki

objek.

Langkah 7 : Pertimbangkan pengenalan dari redudansi terkontrol

Tujuan : untuk menentukan apakah memperkenalkan redudansi yang

dikendalikan oleh aturan normalisasi yang longgar akan meningkatkan

kinerja sistem.

Tahap 7.1 Menggabungkan relasi 1 : 1

Tujuan : untuk memeriksa kembali relasi (1: 1) untuk menentukan

dampak dari menggabungkan relasi ke dalam relasi tunggal.

Kombinasi hanya harus dipertimbangkan untuk relasi yang sering

direferensikan bersama –

sama dan jarang direferensikan secara

terpisah

Tahap 7.2 Mengurangi join duplikasi atribut nonkey pada relasi 1

: *

Tujuan : untuk mengurangi atau menghapus join dari frequent atau

critical queries, mempertimbangkan manfaat yang dapat

mengakibatkan duplikasi satu atau lebih atribut non-key

dari relasi

parent dalam relasi child pada relasi 1: *

Tahap 7.3 Mengurangi join duplikasi atribut foreign

key pada

relasi 1 : *

Tujuan : untuk mengurangi atau menghapus join dari frequent

atau

critical queries,

mempertimbangkan manfaat yang dapat

mengakibatkan duplikasi satu atau lebih atribut foreign

key

dalam

sebuah relasi.

Tahap 7.4 Mengurangi join duplikasi atribut pada relasi * : *

Tujuan : untuk mengurangi jumlah relasi akan bergabung dengan

duplikasi atribut dari salah satu entitas asli dalam relasi menengah.

Tahap 7.5 Memperlihatkan grup pengulangan

Tujuan : untuk menghilangkan grup pengulangan dari model data

logikal sebagai hasil dari kebutuhan bahwa semua entitas dalam

bentuk normal pertama.

Grup pengulangan yang dipisahkan ke relasi baru, membentuk relasi

1:* dengan relasi (parent) asli. Seringkali, grup pengulang

memperkenalkan kembali suatu cara yang efektif untuk meningkatkan

kinerja sistem.

Tahap 7.6 Membuat tabel ekstra

Tujuan : untuk membuat dan mengisi tabel dalam menjalankan

overnight batch bila sistem yang ringan dimuat.

Tahap 7.7 Relasi partisi

Tujuan : untuk mengkombinasikan relasi bersama –

sama sebagai

pendekatan alternatif

pada alamat masalah key

dengan mendukung

relasi yang sangat besar (dan indeks).Penguraian tersebut menjadi

suatu potongan yang lebih kecil dan lebih mudah dikelola disebut

partisi.

Langkah 8: Awasi dan atur sistem operasional

Tujuan : untuk memonitor sistem operasional dan meningkatkan kinerja

sistem untuk memperbaiki keputusan perancangan yang tidak tepat atau

mencerminkan perubahan kebutuhan.

Terdapat nomor faktor yang kita dapat gunakan untuk mengukur

efisiensi:

Transaksi Throughput adalah jumlah transaksi yang dapat diproses

dalam suatu interval waktu. Dalam beberapa sistem, seperti reservasi

penerbangan, transaksi throughput yang tinggi adalah penting untuk

keberhasilan keseluruhan sistem.

Response time adalah waktu yang telah berlalu untuk menyelesaikan

satu transaksi.Dari sudut pandang

user, kami ingin meminimalkan

waktu respon sebanyak mungkin.

Namun, ada beberapa faktor yang mempengaruhi waktu respon bahwa

perancang mungkin telah tidak ada kontrol atas, seperti loading sistem

atau kali komunikasi. Response time dapat diperpendek oleh:

Mengurangi jumlah waktu yang diperlukan sumber daya.

Menggunakan komponen lebih cepat

Disk penyimpanan adalah jumlah ruang disk yang diperlukan untuk

menyimpan file

basis data. Para perancang mungkin ingin

meminimalkan jumlah tempat penyimpanan yang digunakan.

2.2 Tools yang Digunakan

Pada sub bab ini akan dijelaskan mengenai tools yang digunakan dalam proses

analisis data dan perancangan sistem basis data ini.

2.2.1 Diagramming Tools

Tools yang digunakan dalam analisis dan perancangan sistem basis data ini

adalah:

Data Flow Diagram(DFD)

Menurut Whitten et al. (2004, p326) , diagram aliran data adalah model

proses yang digunakan untuk menggambarkan aliran data melalui sebuah

sistem dan tugas atau pengolahan yang dilakukan sistem. Hanya ada tiga

simbol dan satu koneksi dalam DFD yaitu :

Proses

adalah kerja yang dilakukan pada atau sebagai respons terhadap

aliran data masuk atau kondisi.

Gambar 2.11 Simbol Proses

Data flow

menunjukkan input data ke proses atau output

data (atau

informasi) dari proses. Data flow

juga digunakan untuk menunjukkan

pembuatan, pembacaan, penghapusan atau pembaruan data dalam file atau

database.

Gambar 2.12 Simbol Data Flow

External Agent

mendefinisikan orang, unit organisasi, sistem atau

organisasi luar yang berinteraksi dengan sistem

Gambar 2.13 Simbol External Agent

Data store

adalah penyimpanan data yang ditunjukan untuk penggunaan

selanjutnya.Sinonimnya adalah file dan database.

Gambar 2.14 Simbol Data Store

Flowchart

Menurut Mulyadi (2001, p60), bagan alir dokumen (flow chart ) digunakan

untuk menggambarkan aliran dokumen dalam sistem tertentu. Adapun

simbol yang digunakan dalam bagan alir dokumen yaitu :

Dokumen

Menggambarkan semua

jenis dokumen, formulir yang diperlukan untuk

merekan data terjadinya suatu transaksi.

Gambar 2.15 – Simbol Dokumen

Penghubung pada halaman yang sama ( on-page connector)

Karena keterbatasan ruang halaman kertas untuk menggambar, maka

diperlukan simbol penghubung untuk memungkinkan aliran dokumen

berhenti di suatu lokasi pada halaman tertentu dan kembali berjalan di

lokasi lain pada halaman yang sama.

Gambar 2.16 Simbol on-page Connector

Kegiatan manual

Menggambarkan kegiatan manual seperti : menerima order pembeli,

mengisi formulir.

Gambar 2.17 Simbol Kegiatan Manual

Keputusan

Menggambarkan keputusan yang harus dibuat dalam proses pengolahan

data.

Gambar 2.18 Simbol Keputusan

Garis alir (flowline)

Menggambarkan arah proses pengolahan data. Anak panah tidak

digambarkan jika dokumen mengalir ke bawah dan ke kanan.

Gambar 2.19 Simbol Garis Alir (flowline)

Mulai atau akhir

Menggambarkan awal dan akhir suatu sistem akuntansi.

Gambar 2.20 Simbol Mulai atau Akhir

Entity-Relationship Diagram(ERD)

Entity –

Relationship Diagram adalah suatu model untuk menjelaskan

hubungan antara data dalam basis data berdasarkan objek – objek data yang

mempunyai hubungan antar relasi.

ERD mempunyai tiga elemen dasar :

Entity types

Dikenal juga sebagai object types. Entity types dapat merepresentasikan

objek-objek fisikal seperti : buku, orang , dan tempat , dan lain – lain.

MsCustomer

Gambar 2.21 Entity Types

Relationship

Nama dari hubungan diantara entity types , sebuah relationship

merepresentasikan hubungan dua arah diantara entitas –

entitas

(bidirectional).

Gambar 2.22 Relationship

Attributes

Setiap entitas pasti mempunyai elemen yang disebut attribute

yang

berfungsi untuk mendeskripsikan karakteristik dari entitas tersebut. Isi dari

attribute mempunyai sesuatu yang dapat mengidentifikasikan isi elemen

satu dengan yang lain.

MsCustomer

CustomerID

CustomerName

CustomerAddress

CustomerPhone

Gambar 2.23 Simbol Attributes

State Transition Diagram (STD)

State Transition Diagram menurut Whitten, Bentley dan Dittman

(2004, p673), state transition diagram (STD) adalah suatu alat yang

digunakan untuk menggambarkan urutan dan variasi dari layar yang dapat

terjadi selama suatu sesi pengguna. Notasi yang digunakan dalam STD

adalah:

State adalah kumpulan suatu keadaan atau atribut – atribut yang mencirikan

benda atau orang pada keadaan, waktu dan kondisi tertentu.

Gambar 2.24 Notasi State

Transition State, menunjukkan perubahan state ditandakan dengan tanda

panah.

Kondisi

Aksi

Gambar 2.25 Notasi Transition State

Suatu STD dapat menjadi cukup besar, terutama ketika semua input,

output, help, dan layar-layar lainnya dimasukkan ke dalam diagram. Maka

dari itu, umumnya diagram dipisah menjadi beberapa diagram yang lebih

sederhana dan lebih mudah dibaca. Ada 2 hal yang perlu ditambahkan

untuk melengkapi STD, yaitu:

Kondisi adalah keadaan lingkungan luar yang dapat dideteksi oleh sistem

dan dapat menyebabkan perubahan state. Kondisi dapat berubah sinyal,

interrupt , dan lainnya.

Aksi adalah apa yang dilakukan sistem jika ada perubahan state. Aksi dapat

menghasilkan keluaran, tampilan pesan pada layar pengguna, membuat

kalkulasi, dan lainnya.

2.2.2 Software Tools

Software tools yang digunakan dalam perancangan sistem basis data

untuk PT.Datacomindo Mitrausaha antara lain :

PHP (Hypertext Preprocessor)

Software tool yang digunakan dalam pembuatan sistem ini adalah PHP

(Hypertext Preprocessor) yang merupakan bahasa pemrograman script

yang paling banyak dipakai saat ini atau dalam kata lain bisa diartikan

sebuah bahasa pemrograman web

yang bekerja di sisi server (server side

scripting) yang dapat melakukan koneksi pada database yang di mana hal

itu tidak dapat dilakukan hanya dengan menggunakan sintaks-sintaks

HTML biasa. PHP banyak dipakai untuk memrogram situs web dinamis,

walaupun tidak tertutup kemungkinan digunakan untuk pemakaian lain.

Sistem Manajemen Basis Data (DBMS)

Sistem Manajemen Basis Data yang digunakan dalam pembuatan sistem ini

adalah Microsoft SQL Server. SQL Server

adalah RDBMS (Relational

Database Management System) yang dikembangkan oleh Microsoft. SQL

Server dapat digunakan sebagai basis data untuk kebutuhan personal,

seperti basis data pada Windows Mobile Device serta aplikasi yang

menggunakan basis data dengan banyak server.

2.3

Pemahaman Objek Studi

Pada sub bab ini akan dijelaskan mengenai pemahaman –

pemahaman yang

berhubungan dengan objek studi pada skripsi ini.

2.3.1 Penjualan

Menurut Kotler (2006, p457), penjualan merupakan proses dimana

kebutuhan pembeli dan penjualan dipenuhi, melalui antar pertukaran informasi

dan kepentingan.

Menurut Mulyadi (2001,p202), dilihat dari segi pembayarannya, maka

penjualan dapat dikelompokkan menjadi 2, yaitu :

Penjualan Kredit

Penjualan kredit dilakukan oleh perusahaan jika order dari pelanggan telah

dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka

waktu tertentu perusahaan memiliki piutang kepada pelanggannya.

Kegiatan penjualan secara kredit ini ditangai oleh perusahaan melalui

sistem penjualan kredit.

Penjualan Tunai

Dalam transaksi penjualan tunai, barang atau jasa baru diserahkan oleh

perusahaan kepada pelanggan apabila perusahaan telah menerima

pembayaran tunai dari pelanggan.

2.3.1.1 Fungsi yang Terkait Dalam Penjualan

Menurut Mulyadi (2001, p204), fungsi yang terkait dalam sistem

penjualan kredit, antara lain :

Fungsi kredit

Dalam transaksi penjualan kredit dengan kartu kredit, fungsi ini

bertanggung jawab atas pemberian kartu kredit kepada pelanggan

terpilih.

Fungsi penjualan

Fungsi penjualan bertanggung jawab melayani kebutuhan barang

pelanggan. Fungsi penjualan mengisi faktur penjualan kartu kredit

untuk memungkinkan fungsi gudang dan fungsi pengiriman

melaksanakan penyerahan barang kepada pelanggan.

Fungsi gudang

Fungsi gudang menyediakan barang yang diperlukan oleh pelanggan

sesuai dengan yang tercantum dalam tembusan faktur penjualan kartu

kredit yang diterima dari fungsi penjualan.

Fungsi pengiriman

Fungsi pengiriman bertanggung jawab untuk menyerahkan barang

yang kuantitas, mutu, dan spesifikasinya sesuai dengan yang

tercantum dalam tembusan faktur penjualan kartu kredit yang

diterima dari fungsi penjualan. Fungsi ini juga bertanggung jawab

untuk memperoleh tanda tangan dari pelanggan di atas faktur

penjualan kartu kredit sebagai bukti telah diterimanya barang yag

dibeli oleh pelanggan.

Fungsi akuntansi

Fungsi akuntansi bertanggung jawab untuk mencatat transaksi

bertambahnya piutang kepada pelanggan ke dalam kartu piutang

berdasarkan faktur penjualan kartu kredit yang diterima dari fungsi

pengiriman. Di samping itu, fungsi akuntansi bertanggung jawab atas

pencatatan transaksi penjualan di dalam jurnal penjualan.

Fungsi penagihan

Fungsi penagihan bertanggung jawab untuk membuat surat tagihan

secara periodik kepada pemegang kartu kredit.

2.3.1.2 Jaringan Prosedur yang Membentuk Sistem Penjualan

Jaringan prosedur yang membenuk sistem penjualan dengan kartu

kredit adalah :

Prosedur order penjualan

Dalam prosedur ini, fungsi penjualan menerima order dari pembeli

dan menambahkan informasi penting pada surat order dari pembeli.

Fungsi penjualan kemudian membuat faktur penjualan kartu kredit

dan mengirimkannya kepada berbagai fungsi yang lain untuk

memungkinkan fungsi tersebut memberikan kontribusi dalam

melayani order dari pembeli.

Prosedur pengiriman barang

Dalam prosedur ini, fungsi gudang menyiapkan barang yang

diperlukan oleh pembeli dan fungsi pengiriman mengirimkan barang

kepada pembeli sesuai dengan informasi yang tercantum dalam

faktur penjualan kartu kredit yang diterima dari fungsi gudang. Pada

saat penyerahan barang, fungsi pengiriman meminta tanda tangan

penerimaan barang dari pemegang kartu kredit atas faktur penjualan

kartu kredit.

Prosedur pencatatan piutang

Dalam prosedur ini, fungsi akuntansi mencacat tembusan faktur

penjualan kartu kredit ke dalam kartu piutang.

Prosedur penagihan

Dalam prosedur ini, fungsi penagihan menerima faktur penjualan

kartu kredit dan mengarsipkannya menurut abjad. Secara periodik

fungsi penagihan membuat surat tagihan dan mengirimkannya

kepada pemegang

kartu kredit perusahaan dilampiri dengan faktur

penjualan kartu kredit.

Prosedur pencatatan penjualan

Dalam prosedur ini, fungsi akuntansi mencatat transaksi penjualan

kartu kredit ke dalam jurnal penjualan.

2.3.1.3 Dokumen pada Sistem Penjualan

Dokumen yang digunakan untuk melaksanakan sistem penjualan

kredit, antara lain :

Faktur penjualan kartu kredit

Dokumen ini digunakan untuk merekam transaksi penjualan kredit

dengan kartu kredit. Lembar ke-1 dan ke-2 berfungsi sebagai dasar

pembuatan surat tagihan yang secara periodik dibuat oleh fungsi

penagihan dan dikirimkan ke pelanggan. Oleh karena itu, fungsi

pengiriman harus mendapatkan tanda tangan di atas faktur penjualan

kartu kredit lembar ke-1 dan ke-2 pada saat fungsi tersebut

menyerahkan barang kepada pelanggan. Lembar ke-3 berfungsi

sebagai perintah kepada gudang untuk menyiapkan barang yang

dibutuhkan oleh pelanggan, dan lembar ke-4 berfungsi sebagai

perintah pengiriman barang kepada fungsi pengiriman. Lembar ke-2

dokumen ini tetap disimpan di dalam arsip fungsi akuntansi, dan

lembar ke-1 dilampirkan pada surat tagihan yang dikirimkan secara

periodik kepada pelanggan.

Surat tagihan

Surat tagihan ini merupakan turnaround document yang isinya dibagi

menjadi dua bagian : bagian atas merupakan dokumen yang

harus

disobek dan dikembalikan bersama cek oleh pelanggan ke

perusahaan, sedangkan bagian bawah berisi rincian transaksi

pembelian yang dilakukan pelanggan dalam periode tertentu.

2.3.2 Pembelian

Menurut Mulyadi (2001, p299), sistem akuntansi pembelian digunakan

dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan.

Transaksi pembelian dapat digolongkan menjadi dua : pembelian lokal dan

impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri,

sedangkan pembelian impor adalah pembelian dari pemasok luar negeri.

2.3.2.1 Fungsi yang Terkait dalam Pembelian

Berikut ini fungsi – fungsi yang terkait dalam pembelian, yaitu :

Fungsi gudang

Dalam sistem akuntansi pembelian, fungsi gudang bertanggung

jawab untuk mengajukan permintaan pembelian sesuai dengan posisi

persediaan yang ada di gudang dan untuk menyimpan barang yang

telah diterima oleh fungsi penerimaan. Untuk barang – barang yang

langsung dipakai (tidak diselenggarakan persediaan barang di

gudang), permintaan pembelian diajukan oleh pemakai barang.

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 telah dipilih. Fungsi pembelian membuat perjanjian

syarat pembelian dengan pemasok.

Fungsi penerimaan

Fungsi penerimaan bertanggung jawab untuk melakukan

pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang

diterima dari pemasok berdasarkan pesanan pembelian dan faktur

pembelian dari pemasok guna menentukan mengnai dapat atau

tidaknya barang tersebut diterima oleh perusahaan. Fungsi

penerimaan ini juga bertanggung jawab untuk menerima barang dari

pemasok yang berasal dari transaksi retur penjualan.

Fungsi akuntansi

Fungsi akuntansi yang terkait dalam transaksi pembelian adalah

fungsi pencatat utang dan fungsi pencatat persediaan. 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. Fungsi pencatat persediaan bertanggung jawab untuk mencatat

harga pokok persediaan barang yang dibeli ke dalam kartu

persediaan.

2.3.2.2 Jaringan Prosedur yang Membentuk Sistem Pembelian

Dalam melakukan sistem akuntansi pembelian perlu dilakukan

prosedur yang merupakan tahap –

tahap proses terjadinya transaksi

pembelian. Beberapa prosedur yang membentuk sistem akuntansi

pembelian, antara lain :

Prosedur permintaan pembelian

Dalam prosedur ini, fungsi gudang mengajukan permintaan

pembelian dalam dalam dokumen surat permintaan pembelian kepada

fungsi pembelian. Jika barang tidak disimpan di gudang (barang

langsung pakai) , fungsi yang memakai barang mengajukan

permintaan pembelian langsung ke fungsi pembelian dengan

mengajukan 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 pembelian yang lain,

untuk memungkinkan pemilihan pemasok barang yang diperlukan

oleh perusahaan. Dari pemasok akan mengirim daftar penawaran

harga barang yang dikehendaki.

Prosedur order pembelian

Dalam prosedur ini, fungsi pembelian mengirim order pembelian

kepada pemasok yang dipilih dan memberitahukan kepada unit – unit

organisasi yang lain dalam perusahaan ( contohnya fungsi

penerimaan, fungsi yang meminta barang, dan fungsi pencatat utang)

mengenai order pembelian yang sudah dikeluarkan oleh perusahaan.

Prosedur penerimaan barang

Dalam prosedur ini, fungsi penerimaan barang 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.

Barang yang telah diterima diserahkan ke bagian gudang untuk

disimpan.

Prosedur pencatatan utang

Dalam prosedur ini, fungsi penerimaan memberi laporan penerimaan

barang ke fungsi akuntansi . Fungsi akuntansi juga menerima faktur

dari pemasok untuk dicocokan dengan laporan penerimaan barang.

Setelah itu fungsi akuntansi akan memeriksa dokumen – dokumen

yang berhubungan dengan pembelian dan menyelenggarakan

pencatatan utang atau mengarsipkan dokumen sumber sebagai

catatan utang.

2.3.2.3 Dokumen pada Sistem Pembelian

Dokumen merupakan bukti untuk merekam terjadinya transaksi yang

dilakukan oleh perusahaan. Adapun dokumen yang digunakan dalam

sistem akuntansi pembelian, antara lain.

Surat permintaaan pembelian

Dokumen ini merupakan formulir yang diisi oleh fungsi gudang atau

fungsi pemakai barang untuk meminta fungsi pembelian melakukan

pembelian barang dagangan dengan jenis , jumlah, dan mutu seperti

yang tertera pada surat permintaan pembelian. Surat permintaan

pembelian ini biasanya dibuat 2 lembar untuk setiap permintaan, 1

lembar untuk fungsi pembelian, dan tembusannya untuk arsip yang

meminta barang.

Surat permintaan penawaran harga

Dokumen ini digunakan untuk meminta penawaran harga bagi barang

yang pengadaannya tidak bersifat berulang kali terjadi, yang

menyangkut jumlah rupiah pembelian yang besar.

Surat order pembelian

Dokumen ini digunakan untuk memesan barang kepada pemasok

yang telah dipilih.

Laporan penerimaan barang

Dokumen ini dibuat oleh fungsi penerimaan untuk menunjukkan

bahwa barang yang telah diterima dari pemasok telah memenuhi

jenis, spesifikasi, mutu dan kuantitas seperti yang tercantum dalam

surat order pembelian.

Surat perubahan order pembelian

Terkadang diperlukan perubahan terhadap isi surat order pembelian

yang sebelumnya telah diterbitkan Perubahan tersebut dapat berupa

perubahan kuantitas, jadwal penyerahan barang, spesifikasi ,

penggantian atau hal lain

yang bersangkutan dengan perubahan

bisnis. Biasanya perubahan tersebut diberitahukan kepada pemasok

secara resmi dengan menggunakan surat perubahan order pembelian.

Bukti kas keluar

Dokumen ini dibuat oleh fungsi akuntansi berdasarkan pencatatan

transaksi

pembelian, berfungsi sebagai perintah pengeluaran kas

pembayaran utang kepada pemasok dan sekaligus sebagai surat

pemberitahuan kepada kreditur mengenai maksud pembayaran.

2.3.3 Persediaan

Menurut Warren, Reeve, dan Fess (2008, p398), persediaan (inventory)

digunakan untuk mengindikasikan:

Barang dagang yang disimpan untuk kemudian dijual dalam operasi

bisnis perusahaan.

Bahan yang dipergunakan dalam proses produksi atau yang disimpan

untuk tujuan itu.

Menurut Assauri (2004, p219), persediaan adalah sejumlah bahan –

bahan, parts – parts yang disediakan dan bahan-bahan dalam proses yang

terdapat dalam perusahaan untuk proses produksi, serta barang-barang

jadi atau produk yang disediakan untuk memenuhi permintaan dari

konsumen atau langganan setiap waktu.

Menurut Mulyadi(2001, p553), persediaan terdiri dari : persediaan produk

jadi, persediaan produk dalam proses, persediaan bahan baku, persediaan

bahan penolong, persediaan bahan habis pakai pabrik, persediaan suku

cadang.

2.3.3.1 Fungsi yang Terkait dalam Persediaan

Berikut ini fungsi – fungsi yang terkait dalam persediaan , yaitu :

Panitia penghitungan fisik persediaan

Panitia ini berfungsi untuk melaksanakan penghitungan fisik

persediaan dan menyerahkan hasil penghitungan fisik tersebut kepada

bagian kartu persediaan untuk digunakan sebagai dasar adjustment

terhadap catatan persediaan dalam kartu persediaan.

Fungsi akuntansi

Dalam penghitungan fisik persediaan, fungsi akuntansi bertugas

untuk :

Mencantumkan harga pokok satuan persediaan yang dihitung ke

dalam daftar hasil penghitungan fisik.

Mengalikan kuantitas dan harga pokok per-satuan yang tercantum

dalam hasil daftar penghitungan fisik

Mencantumkan harga pokok total dalam daftar hasil penghitungan

fisik

Melakukan adjustment terhadap kartu persediaan berdasarkan data

hasil penghitungan fisik persediaan.

Membuat bukti memorila 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.

2.3.3.2 Jaringan Prosedur yang Membentuk Sistem Persediaan

Dalam menjalankan sistem persediaan perlu dilakukan prosedur yang

merupakan tahap – tahap proses terjadinya transaksi persediaan. Beberapa

prosedur yang membentuk sistem persediaan, antara lain:

Prosedur pencatatan produk jadi

Prosedur ini merupakan salah satu prosedur dalam sistem akuntansi

biaya produksi. Dalam prosedur ini, dicatat harga pokok produk jadi

yang didebitkan dalam rekening barang dalam proses. Catatan

akuntansi yang digunakan dalam prosedur pencatatan produk jadi

adalah kartu gudang, kartu persediaan dan jurnal umum.

Prosedur pencatatan harga produk jadi yang dijual

Prosedur ini merupakan salah satu prosedur dalam sistem penjualan.

Catatan akuntansi yang digunakan dalam prosedur pencatatan harga

produk jadi yang dijual adalah kartu gudang, kartu persediaan, dan

jurnal umum.

Prosedur pencatatan harga produk jadi yang diterima kembali dari

pembeli

Prosedur ini merupakan salah satu prosedur yang membentuk sistem

retur penjualan. Jika produk jadi yang telah dijual dikembalikan oleh

pembeli, maka transaksi retur penjualan ini akan mempengaruhi

persediaan produk jadi, yaitu menambah kuantitas produk jadi dalam

kartu gudang yang diselenggarakan oleh bagian gudang dan

menambah kuantitas dan harga pokok produk jadi yang dicatat oleh

bagian kartu persediaan produk jadi. Catatan akuntansi yang

digunakan dalam prosedur pencatatan harga pokok produk jadi yang

diterima kembali dari pembeli adalah kartu gudang, kartu persediaan

dan jurnal umum atau jurnal retur persediaan jika perusahaan

menggunakan jurnal khusus.

Prosedur pencatatan tambahan dan penyesuaian kembali harga pokok

persediaan produk dalam proses.

Pencatatan persediaan produk dalam proses biasanya dilakukan oleh

perusahaan pada akhir periode, pada saat dibuat laporan keuangan

bulanan dan laporan keuangan tahunan.

Prosedur pencatatan harga pokok persediaan yang dibeli

Prosedur ini merupakan salah satu prosedur yang membentuk sistem

pembelian. Dalam prosedur ini , dicatat harga pokok persediaan yang

dibeli.

Prosedur pencatatan harga pokok persediaan yang dikembalikan

kepada pemasok.

Prosedur ini merupakan salah satu prosedur yang membentuk sistem

retur pembelian. Jika persediaan yang telah dibeli dikembalikan

kepada pemasok , maka transaksi retur pembelian ini akan

mempengaruhi persediaan yang bersangkutan, yaitu mengurangi

kuantitas persediaan dalam kartu gudnag yang diselenggarakan oleh

bagian gudang serta mengurangi kuantitas dan harga pokok

persediaan dalam kartu penyediaan yang bersangkutan.

Prosedur permintaan dan pengeluaran barang gudang.

Prosedur ini merupakan salah satu prosedur yang membentuk sistem

akuntansi biaya produksi. Pada prosedur ini dicatat harga pokok

persediaan bahan baku, bahan penolong, bahan habis pakai pabrik,

dan suku cadang yang digunakan dalam proses kegiatan produksi dan

kegiatan non produksi.

Prosedur pencatatan tambahan harga pokok persediaan karena

pengembalian barang gudang.

Posedur ini melakukan transaksi pengembalian barang gudang,

mengurangi biaya, dan menambah persediaan barang di gudang .

Jurnal yang dibuat untuk mencatat transaksi tersebut ada di dalam

jurnal umum.

Sistem penghitungan fisik persediaan

Sistem perhitungan fisik persediaan umumnya digunakan oleh

perusahaan untuk menghitung secara fisik persediaan yang disimpan

di gudang. Hasilnya digunakan untuk meminta pertanggungjawaban

bagian gudang mengenai pelaksanaan fungsi penyimpanan dan

pertanggungjawaban bagian kartu persediaan mengenai kendala

catatan persediaan yang diselenggarakan, serta untuk melakukan

penyesuaian terhadap catatan persediaan di bagian kartu persediaan.

2.3.3.3 Dokumen pada Sistem Persediaan

Dokumen merupakan bukti untuk merekam

terjadinya transaksi yang

dilakukan oleh perusahaan.Adapun dokumen yang digunakan dalam

sistem persediaan, antara lain :

Laporan produk selesai

Laporan produk selesai digunakan oleh bagian gudang untuk

mencatat tambahan kuantitas produk jadi dalam kartu gudang.

Bukti memorial

Bukti memorial digunakan untuk mencatat tambahan kuantitas dan

harga pokok persediaan produk jadi dalam kartu persediaan dan

digunakan sebagai dokumen sumber dalam mencatat transaksi

selesainya produk jadi dalam jurnal umum.

Surat order pengiriman

Surat order pengiriman diterima oleh bagian gudang dari bagian

order penjualan.

Setelah bagian gudang mengisi surat order

pengiriman tersebut dengan kuantitas produk jadi yang diserahkan

kepada bagian pengiriman, atas dasar surat order pengiriman tersebut

bagian gudang mencatat kuantitas yang diserahkan ke bagian

pengiriman dalam kartu gudang.

Faktur penjualan

Harga pokok produk jadi yang dijual dicatat oleh bagian kartu

persediaan dalam kartu persediaan atas dasar tembusan faktur yang

diterima oleh bagian tersebut dari bagian penagihan.

Laporan penerimaan barang

Laporan penerimaan barang digunakan oleh bagian gudang untuk

mencatat kuantitas persediaan yang dikirimkan kembali kepada

pemasok ke dalam kartu gudang.

Laporan pengiriman barang

Laporan pengiriman barang digunakan oleh bagian gudang untuk

mencatat kuantitas persediaan yang dikirimkan kembali kepada

pemasok ke dalam kartu gudang.

Bukti kas keluar

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 atau voucher register. Bukti kas

keluar juga dipakai sebagai dasar pencatatan tambahan kuantitas dan

harga pokok persediaan ke dalam kartu persediaan.

Memo kredit

Memo kredit yang diterima dari bagian order penjualan digunakan

oleh bagian kartu persediaan untuk mencatat kuantitas dan harga

pokok produk jadi yang dikembalikan oleh pembeli ke dalam kartu

persediaan.

Memo debit

Memo debit yang diterima dari bagian pembelian digunakan oleh

bagian kartu persediaan untuk mencatat kuantitas dan harga pokok

persediaan yang dikembalikan kepada pemasok ke dalam kartu

persediaan.

Bukti permintaan dan pengeluaran barang gudang

Bukti ini dipakai oleh bagian gudang untuk mencatat pengurangan

persediaan karena pemakaian intern. Bukti ini digunakan oleh bagian

kartu persediaan untuk mencatat berkurangnnya kuantitas dan harga

pokok persediaan karena pemakaian intern. Bukti ini juga digunakan

sebagai dojumen sumber dalam pencatatan pemakaian persediaan ke

dalam jurnal pemakaian bahan baku atau jurnal umum.

Bukti pengembalian barang gudang

Dokumen ini digunakan oleh bagian gudang untuk mencatat

tambahan kuantitas persediaan ke dalam kartu gudang.Dokumen ini

juga dipakai oleh bagian kartu persediaan untuk mencatat tambahan

kuantitas dan harga pokok persediaan ke dalam kartu persediaan ,

untuk mencatat berkurangngnya biaya ke dalam kartu biaya, dan

untuk mencatat pengembalian barang gudang tersebut ke dalam

jurnal umum.

Kartu perhitungan fisik (inventory tag)

Dokumen ini digunakan untuk merekam hasil penghitungan fisik

persediaan. Dalam penghitungan fisik persediaan, setiap jenis

persediaan dihitung dua

kali secara independen oleh penghitung

(counter) dan pengecek (checker). Kartu penghitungan fisik dibagi

menjadi tiga bagian, yang tiap bagian dapat dipisahkan satu dengan

yang lainnya dengan cara menyobeknya pada waktu proses

penghitungan fisik (bagian bawah) disediakan untuk merekam data

hasil penghitungan oleh penghitung pertama.Bagian ke-2 (bagian

tengah) kartu tersebut digunakan untuk merekam hasil penghitungan

yang dilakukan oleh penghitung kedua (pengecek) . Bagian ke-1

(bagian atas) kartu tersebut digunakan dengan cara menggantungkan

bagian kartu tersebut pada tempat penyimpanan barang yang

bersangkutan.

Daftar hasil penghitungan fisik

Dokumen ini digunakan untuk meringkas data yang telah direkam ke

dalam bagian ke -2 kartu penghitungan fisik.