BAB 2 LANDASAN TEORI

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.

6

7

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). 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: a. Data Definition Language (DDL), memungkinkan pengguna untuk mendefinisikan basis data, tipe dan strukturnya serta memberikan batasan pada data untuk disimpan dalam basis data.

8

b. 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. c. DBMS juga menyediakan kontrol akses ke basis data sebagai berikut: 1. Security system, dimana mencegah user yang tidak mempunyai hak akses untuk mengakses basis data. 2. Integrity system, dimana memelihara konsistensi dari data yang disimpan. 3. Concurrency control system, dimana memungkinkan untuk berbagi akses ke basis data. 4. Recovery control system, dimana dapat mengembalikan database ke kondisi semula ketika terjadi kegagalan pada perangkat lunak maupun perangkat keras. 5. 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: 1. Mengontrol Duplikasi Data DBMS dapat mengurangi duplikasi basis data yang terjadi tetapi tidak semua duplikasi data dapat dihilangkan, melainkan hanya dapat dikontrol.

9

2. Konsistensi Data DBMS menjaga agar data didalamnya tetap konsisten dengan cara menghilangkan atau mengontrol duplikasi data. 3. Pengunaan data secara bersama DBMS memungkinkan basis data yang dimiliki oleh organisasi bisa digunakan secara bersama oleh user yang memiliki hak akses. 4. Meningkatkan integritas data Integritas basis data mengacu kepada validitas dan konsistensi dari data yang disimpan. Integritas sendiri biasanya memperdalam arti kata constraintyang berarti basis data tidak diperbolehkan untuk dilanggar oleh pemakai basis data itu sendiri. 5. 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 DBMSdiantara lain: 1. 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

10

keuntungan dari DBMS ini jika tidak dipahami dengan baik maka kompleksitas DBMS bisa menjadi kesulitan tersendiri. 2. Ukuran Kompleksitas dan juga fungsionalitas membuat DBMS menjadi sebuah perangkat lunak yang sangat besar ukurannya, sehingga kita harus memperhitungkan jumlah disk spaceyang besar serta jumlah memory yang besar pula agar DBMS ini bisa berjalan dengan efisien. 3. Harga Harga DBMS sendiri tidaklah murah tergantung dari lingkungan dan juga fungsionalitas yang disediakan oleh DBMS tersebut. 4. Biaya tambahan perangkat keras Disk storageyang diperlukan untuk DBMS dan juga basis data memungkinkan untuk membeli

storage tambahan sehingga perlu

disediakan perangkat keras tambahan . 5. 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.

11

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)

12

2.1.6.1 Database planning Menurut Connolly dan Begg (2005, p285), database planning adalah merupakan aktifitas manajemen yang memungkinkan tahapantahapan 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 : a. Identifikasi rencana dan sasaran dari enterprise termasuk mengenai sistem informasi yang dibutuhkan. b. Evaluasi sistem yang ada untuk menetapkan kelebihan dan kekurangan yang dimiliki c. Penilaian kesempatan IT yang mungkin memberikan keuntungan kompetitif. Tahapan utama yang paling penting dalam database planning adalah menentukan mission statementdan 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 aplikasis 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

13

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.

14

2.1.6.3 Requirement Collection and Analysis Menurut Connolly dan Begg (2005, p288), requirement collection and analysisadalah suatu proses pengumpulan dan analisis informasi mengenai bagian orgnasisasi 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: a. Pendekatan Terpusat Kebutuhan untuk setiap user view digabungkan menjadi sekumpulan kebutuhan b. 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. c. Kombinasi dari terpusat dan integrasi view

15

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.

16

- 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: 1. 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. 2. 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. 3. Perancangan Basis data Fisikal (Physical Database Design) Menurut Connolly dan Begg (2005, p294), perancangan basis data fisikal merupakan suatu proses yang menghasilkan deskripsi

17

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: 1. Mendefinisikan terminologi dari studi referensi 2. Mendaftar 2 atau 3 produk 3. Evaluasi produk 4. 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 :

18

- 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 bass 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),

implementationmerupakan 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 viewyang diinginkan, 3GL dan 4GL untuk membuat program aplikasi. Termasuk transaksi basis

19

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 mengkonvesikan aplikasi yang ada agar dapat digunakan pada basis data yang baru. Tahapan ini dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. DBMSbiasanya memiliki utilitas yang memanggil ulang fileyang 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.

20

2.1.6.11 Operational Maintenence Menurut Connolly dan Begg(2005, p306), Operational maintenence merupakan suatu proses pengawasan dan pemeliharaan sistem setelah instalasi, meliputi: a. Pengawasan performa sistem, jika performa menurun maka menentukan perbaikan atau pengaturan ulang jadwal. b. Pemeliharaan aplikasi basis data jika dibutuhkan c. 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 propertyyang sama, yang di identifikasi oleh enterprisemempunyai eksistensi yang independent. Keberadaannya dapat berupa fisik maupun abstrak. Representasi diagram dari tipe entitas:

Entity Name

Staff

Branch

Gambar 2.2 Representasidiagramatikdari tipe entitasstaff dan branch

21

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 typeadalah 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. Relationship Name

Staff

Branch

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 :

22

3. Binary relationship adalah keterhubungan antar dua tipe entitas. Contoh hubungan binary relationship adalah hubungan has pada gambar dibawah ini: Relationship Name

Staff

Has

Branch

‘Branch Has Staff’ GAMBAR 2.4 Representasi relationship tipe branch memiliki staff - Ternary relationship adalah keterhubungan antar tiga tipe entitas. contoh dari ternary relationshipadalah registers 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.

23

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: 1. 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. 2.

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.

3.

Single – valued Attribute adalah atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalkan entitas Branch memiliki satu nilai untuk atribut branchNo pada setiap kejadian.

4.

Multi-valued Attribute adalah atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misalkan entitas Branch memiliki beberapa nilai untuk atribut telpNo pada setiap kejadian.

5.

Derived Attribute

adalah atribut yang memiliki nilai yang

dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.

24

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 Keyadalah candidate key yang dipilih untuk mengidentifikasikan 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

TypeEntitas

adalah

entitas

yang

keberadaannya bergantung pada entitas lain. Strong TypeEntitas terkadang disebut dengan parent, owner dominant dan Weak Type Entitas disebut child, dependent, subordinate.

25

2.1.7.5 Structural Constraint Menurut Connolly (2005, p356), batasan utama pada relationship disebut multiplicity.Multiplicityadalah 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: a. One-to-One (1:1) Relationships

Gambar 2.5 One to One Relationship 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

26

b. One-to-Many (1:*) Relationships

Gambar 2.7 One to Many Relationship 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

27

c. 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

28

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 keybergantung 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 keybergantung secara transitif pada primary key.

29

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, independentdari semua aspek fisik. Menurut Connolly dan Begg (2005, p442), langkah – langkah yang digunakan antara lain: Langkah 1 : Membangun model data konseptual lokal untuk masingmasing 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.

30

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 (2003, 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 Addressdapat terdiri dari Street, City, PostCode.

31

- Single atau multivalue attributes Single-valued Attribute adalah atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalkan entitas Branchmemiliki satu nilai untuk atribut branchNopada setiap kejadian. Multi-valued Attribute adalah atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misalkan entitas Branch memiliki beberapa nilai untuk atribut telpNopada 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 domainuntuk setiap atribut meliputi kumpulan nilai untuk setiap atribut dan ukuran beserta format atribut.

32

Tahap 1.5 Menentukan atribut candidate dan primary key Tujuan : untuk mengidentifikasi candidate keypada 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

Primary Key adalah candidate key

atau

record

secara

unik.

yang dipilih untuk meng-

identifikasikan setiap kejadian atau recorddari 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 subclassdari sebuah entitas superclass. Jika memilih pendekatan generalisasi, diusahakan untuk mengidentifikasi fitur-fitur umum antar entitas untuk mendefinisikan sebuah entitas superclass generalisasi. Pendekatan agregasi digunakan

33

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

:

34

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.

35

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 hhubungan yang telah teridentifikasi. Pembagian relasi dari sebuah model data diantaranya : 1.

Tipe entitas kuat (Strong Entity)

Pada setiap entitas kuat pada model data, buat sebuah relasi yang memasukkan semua simple atribute dari entitas tersebut. Untuk

36

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). 2.

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,m primary key untuk relasi preference tidak dapat diidentifikasi sampai hubungan states telah dipetakan. 3. 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. 4. 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.

37

5. Tiper relasi recursive one to one (1 : 1) Relasi recursive 1 : 1, aturan untuk partisipasi sebagai penggambaran relasi one to one (1 : 1). 6. Tipe relasi superclass atau subclass Pada setiap relasi superclass atau subclass pada model data konseptual, kita mengiddentifikasi entitas superclass sebagai parent entity dan entitas subclass sebagai child entity. 7. Tipe relasi binary many to many (* : *) Pada setiap relasi binary * : *, buat sebuah hubungan untuk menghadirkan relasi dan menyertakan atribut apa saja yang termasuk dalam baguan daari relasi. 8. Tipe relasi kompleks Pada setiap relasi kompleks, buat sebuah hubungan yang menghadirkan relasi dan sertakan beberapa atribut yang merupakan bagian dari relasi. 9. 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 :

38

1. First normal form (1NF) Menghilangkan kelompok yang berulang. 2. Second normal form (2NF) Menghilangkan ketergantungan parsial pada primary key. 3. Third normal form (3NF) Menghilangkan ketergantungan transitif pada primary key. 4. 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 daa dari ketidakkonsistenan.

39

Lima tipe dari batasan integritas yang harus diperhatikan : 1. Data yang dibutuhkan Beberapa atribut harus memilki sebuah nilai yang valid (tidak mengandung null). Contoh : setiap anggota staff harus memiliki jabatan. 2. 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. 3. Integritas entitas Primary key dari entitas tidak boleh null. Contoh : setiap baris dari relasi staff harus memiliki nilai untuk atribut primary key. 4. Integritas referensial Sebuah foreign key menghubungkan setiap baris pada relasi child kedalam relasi parent dengan menyamakan nilai dari candidate key. 5. Batasan perusahaan Perhatikan batasan perusahaan yang dikenal sebagai peraturan bisnis.

40

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 view. Model

data

logikal

didokumentasikan.

lokal

Untuk

pada

view

menyelesaikan

harus tahapan

diselesaikan ini,

dan

dilakukan

peninjauan model logikal dan dukungan dokumentasi dengan user.

Tahap 2.6 Menggabungkan model data logikal kedalam model global Tujuan : untuk menggabungkanmodel 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. 1. Review nama-nama dan isi dari entitas dan relasi dan candidate keys nya.Masalah dapat muncull ketika dua atau lebih entitas : - Memiliki nama yang sama tetapi pada kenyataannya berbeda (homonim). - Sama tetapi berbeda namanya(sinonim). 2. Review nama-nama dan isi dari relasi atau foreign keys.

41

3. 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. 4. Memasukkan (tanpa menggabungkan) entitas atau relasi unik pada tiap-tiap model data lokal. 5. Menggabungkan relasi atau foreign keys dari model data lokal. Aktifitas pada langkah ini antara lain : - Menggabungkan relasi atau foregn keys dengan nama yang sama dan tujuan yang sama. - Menggabungkan relasi atau fireign keys dengan nama yang berbeda tetapi tujuan yang sama . 6. Memasukkan (tanpa menaggabungkan) relasi atau fireign keys unik pada setiap model data logikal. 7. Memeriksa entitas yang hilang dan relasi atau fireign keys. 8. Memeriksa foreign keys. 9. Memeriksa batasan integritas. 10. Menggambar global ER/ diagram relasi. 11. Update dokumentasi.

42

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.

43

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.

44

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.

45

- 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.

46

- Atribut yang digunakan paling sering untuk mengakses tuple dalam suatu relasi dalam urutan yang atribut. Xxxxxx 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 merancan 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.

47

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 userdapat 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 joindari 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: *.

48

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.

49

Tahap 7.7 Relasi partisi Tujuan : untuk mengkombinasikan relasi bersama – sama sebagai pendekatan alternative 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:

50

- 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 toolsyang digunakan dalam proses analisis data dan perancangan sistem basis data ini . 2.2.1 Analisis dan Perancangan Tools yang digunakan dalam analisis dan perancangan sistem basis data ini adalah: a. 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 : 1. Proses adalah kerja

yang dilakukan pada atau sebagai respons

terhadap aliran data masuk atau kondisi

Gambar 2.11 Simbol Proses

51

2. 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

3. External Agent mendefinisikan orang, unit organisasi, sistem atau organisasi luar yang berinteraksi dengan sistem

Gambar 2.13 Simbol External Agent

4. Data store adalah penyimpanan data yang ditunjukan untuk penggunaan selanjutnya.Sinonimnya adalah file dan database.

Gambar 2.14 Simbol Data Store

52

b. 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 : 1. Dokumen Menggambarkan semua jenis dokumen, formulir yang diperlukan untuk merekan data terjadinya suatu transaksi.

Gambar 2.15 – Simbol Dokumen

2. 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

53

3. Kegiatan manual Menggambarkan kegiatan manual seperti : menerima order pembeli, mengisi formulir.

Gambar 2.17 Simbol Kegiatan Manual 4. Keputusan Menggambarkan keputusan yang harus dibuat dalam proses pengolahan data

Gambar 2.18 Simbol Keputusan

5. 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)

54

6. Mulai atau Akhir Menggambarkan awal dan akhir suatu sistem akuntansi.

Gambar 2.20 Simbol Mulai atau Akhir

c. Use-case Diagram Menurut Whitten, Bentley dan Dittman (2004, p257), use-case diagram adalah suatu diagram yang menggambarkan interaksi antara sistem eksternal dan pengguna. Dengan kata lain, secara grafis menggambarkan siapa yang akan menggunakan sistem dan dengan cara apa pengguna mengharapkan untuk berinteraksi dengan sistem. Notasi yang digunakan dalam use-case diagram antara lain : 1. Menurut Munawar (2005, p64) , Actoradalah abstraction dari orang dan sistem yang lain yang mengaktifkan fungsi dari target sistem.

Gambar 2.21 Simbol Actor

55

2. Menurut Munawar (2005, p65), Use case adalah abstraksi dari interaksi antara sistem dan actor. Use case harus merupakan ‘apa’ yang dikerjakan software aplikasi, bukan ‘bagaimana’ software aplikasi mengerjakannya.

Gambar 2.22 Simbol Use Case 3. Menurut Munawar (2005, p66) , Stereotype adalah sebuah model khusus yang terbatas untuk kondisi tertentu. Untuk menunjukkan stereotype digunakan simbol “<<” diawalnya dan ditutup “>>” diakhirnya. <<extend>> digunakan untuk menunjukkan bahwa satu use case merupakan tambahan fungsional dari use case yang lain jika syarat atau kondisi tertentu dipenuhi, <> digunakan untuk menggambarkan bahwa suatu use case seluruhnya merupakan fungsionalitas dari use case lainnya. d. 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.

56

ERD mempunyai tiga elemen dasar : 1. 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.23 Simbol Entity Types 2. Relationships Nama dari hubungan diantara entity types , sebuah relationship merepresentasikan hubungan dua arah diantara entitas – entitas (bidirectional).

Gambar 2.24 Simbol Relationships

3. 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.

57

MsCustomer PK

CustomerID CustomerName CustomerAddress CustomerPhone

Gambar 2.25 Simbol Attributes

e. 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: 1.State, adalah kumpulan suatu keadaan atau atribut – atribut yang mencirikan benda atau orang pada keadaan, waktu dan kondisi tertentu.

58

Gambar 2.26 Notasi State

2. Transition State, menunjukkan perubahan state ditandakan dengan tanda panah. Kondisi

Aksi Gambar 2.27 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: 1. Kondisi adalah keadaan lingkungan luar yang dapat dideteksi oleh sistem dan dapat menyebabkan perubahan state. Kondisi dapat berubah sinyal, interrupt , dan lainnya. 2. 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

Programming Tools Programming tools yang digunakan dalam perancangan sistem ini adalah NetBeans yang merupakan platform aplikasi framework untuk

59

aplikasi java desktop yang menggunakan gabungan bahasa pemograman

dari Java, PHP, C/C++, dan HTML 5. NetBeans IDE ditulisa dalam Java dan dapat berjalan di Windows, OSX, Linux, Solaris dan paltform lain yang mendukung JVM kompatibel. NetBeans ini telah dikolaborasikan dengan beberapa jenis aplikasi, seperti aplikasi desktop dan aplikasi berbasis web.

2.2.3

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.

60

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

penjualan

dapat

dikelompokkan

menjadi

2,

yaitu

:

a. 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. b. 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 : a. Fungsi kredit Dalam transaksi penjualan kredit dengan kartu kredit, fungsi ini bertanggung jawab atas pemberian kartu kredit kepada pelanggan terpilih. b. Fungsi penjualan Fungsi penjualan bertanggung jawab melayani kebutuhan barang pelanggan. Fungsi penjualan mengisi faktur penjualan kartu kredit

61

untuk memungkinkan fungsi gudang dan fungsi pengiriman melaksanakan

penyerahan

barang

kepada

pelanggan.

c. 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. d. 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. e. 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. f. Fungsi penagihan Fungsi penagihan bertanggung jawab untuk membuat surat tagihan secara

periodik

kepada

pemegang

kartu

kredit.

62

2.3.1.2 Jaringan Prosedur yang Membentuk Sistem Penjualan Jaringan prosedur yang membenuk sistem penjualan dengan kartu kredit adalah : a. 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. b. Prosedur pengiriman barang Dalam prosedur ini, fungsi gudang menyiapkan barang yang diperlukan oleh pembeli dan gunfsi 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 kredut du atas faktur penjualan kartu kredit. c. Prosedur pencatatan piutang Dalam prosedur ini, fungsi akuntansi mencacat tembusan faktur penjualan

kartu

kredit

ke

dalam

kartu

piutang.

63

d. 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. e. 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 : a. 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

64

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. b. 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 :

65

a. 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 persiadaan barang di gudang), permintaan pembelian diajukan oleh pemakai barang. b. 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. c. 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. d. Fungsi akuntansi

66

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 : a. 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. b. Prosedur permintaan penawaran harga dan pemilihan pemasok.

67

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. c. 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. d. 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. e. 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

68

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 . a. 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. b. 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. c. Surat order pembelian Dokumen ini digunakan untuk memesan barang kepada pemasok yang telah dipilih. d. Laporan penerimaan barang

69

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. e. 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. f. 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: 1. Barang dagang yang disimpan untuk kemudian dijual dalam operasi bisnis perusahaan. 2. Bahan yang dipergunakan dalam proses produksi atau yang disimpan untuk tujuan itu.

70

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 : a. 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

adjustmentterhadap catatan persediaan dalam kartu persediaan. b. Fungsi akuntansi Dalam penghitungan fisik persediaan, fungsi akuntansi bertugas untuk : 1. Mencantumkan harga pokok satuan persediaan yang dihitung ke dalam daftar hasil penghitungan fisik. 2. Mengalikan kuantitas dan harga pokok per-satuan yang tercantum dalam hasil daftar penghitungan fisik 3. Mencantumkan

harga

penghitungan fisik

pokok

total

dalam

daftar

hasil

71

4. Melakukan adjustment terhadap kartu persediaan berdasarkan data hasil penghitungan fisik persediaan. 5. Membuat bukti memorila untuk mencatat adjustment data persediaan dalam jurnal umum berdasarkan hasil penghitungan fisik persediaan. c. Fungsi Gudang Dalam sistem penghitungan fisik persediaan , fuungsi gudnag 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: a. 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. b. Prosedur pencatatan harga produk jadi yang dijual Prosedur ini merupakan salah satu prosedur dalam sistem penjualan. Catatan akuntansi yang digunakan dalam prosedur pencatatan harga

72

produk jadi yang dijual adalah kartu gudang, kartu persediaan, dan jurnal umum. c. 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. d. 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. e. 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.

73

f. 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. g. 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. h. 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.

74

i. 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 merekan terjadinya transaksi yang dilakukan oleh perusahaan.Adapun dokumen yang digunakan dalam sistem persediaan, antara lain : a. Laporan produk selesai Laporan produk selesai digunakan oleh bagian gudang untuk mencatat tambahan kuantitas produk jadi dalam kartu gudang. b. 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.

75

c. 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. d. 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. e. Laporan penerimaan barang Laporan penerimaan barang digunakan oleh bagian gudang untuk mencatat kuantitas persediaan yang dikirimkan kembali kepada pemasok ke dalam kartu gudang. f. Laporan pengiriman barang Laporan pengiriman barang digunakan oleh bagian gudang untuk mencatat kuantitas persediaan yang dikirimkan kembali kepada pemasok ke dalam kartu gudang.

76

g. 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. h. 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. i. 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. j. 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

77

sebagai dojumen sumber dalam pencatatan pemakaian persediaan ke dalam jurnal pemakaian bahan baku atau jurnal umum. k. 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. l. 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.

78

m. Daftar hasil penghitungan fisik Dokumen ini digunakan untuk meringkas data yang telah direkam ke dalam bagian ke -2 kartu penghitungan fisik.