6 BAB 2 LANDASAN TEORI
2.1
Teori-teori Database 2.1.1
Pengertian Database Definisi database berdasarkan Connolly (2002, p14) adalah kumpulan
dari data-data yang saling berhubungan secara logikal, dan ada deskripsi dari data yang didesign untuk memenuhi informasi yang dibutuhkan oleh perusahaan. Penjelasan lebih tentang definisi database adalah sebuah tempat penyimpanan besar data yang dapat digunakan secara terus menerus oleh banyak departemen dan user. Semua bagian data saling terintegrasi dengan jumlah duplikasi minimum. Database tidak hanya dimiliki oleh satu departemen tetapi merupakan bagian sumber daya perusahaan. Database tidak hanya menangani data operasional perusahaan tetapi juga menangani deskripsi dari data tersebut. Oleh karena itu database juga diartikan sebagai a self-describing collection of integrated records, yaitu kumpulan record terintegrasi yang menjelaskan record itu sendiri. Penjelasan dari data dikenal sebagai system catalog (data dictionary atau meta-data). Yang dimaksud dengan data-data yang saling berhubungan secara logikal adalah saat seseorang menganalisa kebutuhan informasi dari perusahaan, yang perlu diperhatikan adalah orang tersebut perlu mengidentifikasi entity, atribut dan relationship. Entity adalah objek yang berbeda-beda dalam perusahaan yang direpresentasikan dalam database, contohnya orang, tempat, benda, konsep, atau
7 kejadian). Atribut adalah bagian yang menjelaskan beberapa aspek dari objek yang ingin dicatat. Relationship adalah hubungan antar entity. Pengertian database berdasarkan Hartono (1999, p711) adalah kumpulan dari data yang saling berhubungan satu dengan yang lainnya, tersimpan di perangkat
keras
komputer
dan
digunakan
perangkat
lunak
untuk
memanipulasinya. Database merupakan salah satu komponen yang penting dalam sistem informasi, karena merupakan basis dalam menyediakan informasi bagi para pemakai. Penerapan database dalam sistem informasi disebut dengan database system. Database system adalah suatu sistem informasi yang mengintegrasikan kumpulan dari data yang saling berhubungan satu dengan yang lainnya dan membuatnya tersedia untuk beberapa aplikasi yang bermacammacam di dalam suatu organisasi. Definisi database berdasarkan Whitten (2000, p470) adalah koleksi filefile yang interrelated (berhubungan). Database tidak hanya berupa koleksi filefile. Record dari tiap file harus memiliki relationship (bayangkan sebagai pointer) ke record file lain. Dalam database environment, aplikasi akan dibangun sekitar database terintegrasi. Pada umumnya, database tidak sepenuhnya tergantung pada aplikasi yang akan menggunakannya. Dengan kata lain, database yang sudah ada, aplikasi yang baru dapat dibangun untuk membagi atau menyebarkan database tersebut. Menurut www.webpodia.com database adalah koleksi dari informasi yang disusun dengan berbagai cara dimana program komputer dapat memilih secara cepat data yang diinginkan.
8 2.1.2
Database Management System (DBMS) DBMS adalah sebuah sistem perangkat lunak yang memungkinkan user
untuk menjelaskan, membuat, mengatur dan mengontrol akses untuk database (Connolly, 2002, p16). DBMS adalah perangkat lunak yang berinteraksi dengan program aplikasi user dan database. Berikut adalah fasilitas yang diberikan oleh DBMS: o Membolehkan user untuk mendefinisikan database, biasanya dengan melalui Data Definition Language (DDL). o Membolehkan user untuk insert (memasukkan), update (mengganti), delete (menghapus) dan retrieve (mencari dan mengembalikan) data dari database, biasanya melalui Data Manipulation Language (DML). o Menyediakan akses pengontrolan untuk database, contohnya pada sistem keamanan (melindungi database dari user yang tidak berwenang), sistem integritas (mengatur konsistensi dari data yang disimpan), sistem kontrol konkurensi (yang membolehkan pembagian akses database), sistem kontrol perbaikan (yang menyimpan database untuk tindak selanjutnya saat terjadi kerusakan hardware atau software), katalog user-accessible (yang mencakup deskripsi dari data pada database). Berikut akan dipaparkan tentang keuntungan dan kerugian dari DBMS menurut Connolly (2002, p25). Keuntungan dari DBMS yaitu: o Kontrol atas data redudancy o Konsistensi data o Mendapat informasi tambahan dari jumlah data yang sama o Pembagian data
9 o Peningkatan integritas data o Peningkatan keamanan o Peningkatan standard o Economy of scale o Keseimbangan dari kebutuhan yang bertentangan o Peningkatan aksesibilitas data dan responsivitas o Peningkatan produktivitas o Peningkatan pengaturan melalui data independence o Peningkatan konkurensi o Peningkatan pelayanan backup dan recovery Sedangkan kerugiannya yaitu: o Kompleksitas o Ukuran o Biaya dari DBMS o Biaya hardware tambahan o Biaya konversi o Perfomance o Dampak lebih besar jika gagal Pengertian DBMS menurut Hartono (1999, p731) yaitu paket perangkat lunak yang komplek digunakan untuk memanipulasi database. Banyak sekali paket DBMS yang telah beredar. Untuk memilih paket mana yang tepat untuk digunakan, ada beberapa pedoman untuk menentukannya: 1. Harus mudah digunakan. 2. Mempunyai prosedur backup untuk membuat file pelindung.
10 3. Dapat memberikan berita bila terjadi kegagalan sistem. 4. Banyaknya file yang dapat dibuka serentak pada suatu saat. 5. Kemampuan untuk merubah nilai-nilai default yang sudah ditentukan. 6. Kemampuan dari operasi aritmatikanya. 7. Kemampuan untuk mengedit data dengan mudah. 8. Kemampuan untuk mengurutkan data. 9. Kecepatan pengolahannya. 10. Kemampuan pembuatan laporan. 11. Kemampuan memodifikasi struktur data. 12. Kemampuan mempertemukan, menggabung atau mengupdate dengan dua atau lebih file. 13. Kemampuan indexing. 14. Mempunyai query language. 15. Kemampuan berhubungan dengan program yang lain. 16. Jumlah record yang dapat ditangani oleh masing-masing file. 17. Jumlah karakter per record yang dapat digunakan. 18. Jumlah dari field yang dapat ditentukan dalam sebuah file. 19. Panjang maksimum suatu field. 20. Jumlah dari field kunci dalam satu file. 21. Kemampuan hubungan dengan file yang lain. 22. Kemampuan menggunakan hard disk. 23. Kemampuan untuk digunakan pada sistem multi user. 24. Harga dari paket tersebut. 25. Dukungan purna jual bila ada versi yang lebih baru.
11 DBMS (Eaglestone, 2001, p3) adalah program komputer dengan tipe tertentu yang digunakan oleh program aplikasi untuk mengatur dan menyediakan akses ke data yang disimpan. DBMS sekarang merupakan komponen standard dari semua sistem komputer, berskala dari mainframe besar sampai ke PC kecil. Definisi DBMS berdasarkan Whitten (2000, p477) yaitu software komputer spesial yang tersedia pada penjual komputer yang digunakan untuk membuat, mengakses, mengontrol, dan mengatur database. Pusat dari DBMS biasanya disebut database engine. Mesin berespon pada perintah spesifik untuk menciptakan struktur database dan kemudian untuk membuat, meng-update, membaca dan menghapus record pada database. (Whitten, 2000, p479) Banyak DBMS tidak memerlukan penggunaan DDL untuk membangun database atau DML untuk mengakses database. Bahkan, DBMS menyediakan tool dan command sendiri untuk menyelesaikan tugas. Banyak DBMS juga terdapat penulisan laporan dan inquiry tool (alat pemeriksaan) yang membolehkan user untuk mengakses dan memformat data tanpa menggunakan DML secara langsung. Dalam lingkungan DBMS dikenal 5 komponen utama (Connolly, 2002, p18), yaitu: o Hardware DBMS dan aplikasi butuh hardware untuk berjalan. Hardware yang dimaksud bisa berupa single personal computer (PC), sampai ke single mainframe ke jaringan komputer.
12 o Software Komponen software berisi software DBMS itu sendiri dan program aplikasi bersama dengan sistem operasi, termasuk software jaringan apabila DBMS digunakan dalam jaringan. o Data Data merupakan komponen DBMS yang paling penting berdasarkan pandangan dari user. Data merupakan jembatan yang menghubungkan komponen mesin dengan komponen manusia. o Procedure Procedure adalah instruksi dan aturan yang mengatur design dan penggunaan database. o People Komponen terakhir adalah orang-orang yang terlibat dalam sistem database.
2.1.3
Data Definition Language (DDL) Yang dimaksud dengan Data Definition Language (DDL) menurut
Connolly (2002, p40) adalah bahasa yang membolehkan DBA (Database Administrator – yang bertanggung jawab untuk realisasi fisikal database seperti design fisikal, implementasi, keamanan dan kontrol intregritas) atau user untuk mendeskripsikan dan menamakan entity, atribut, dan relationship yang dibutuhkan dalam aplikasi, bersama dengan keamanan dan integritas yang berkaitan.
13 Berdasarkan Hartono (1999, p735), DDL memiliki fungsi utama untuk mendefinisikan data dalam database secara logika, diantaranya yaitu: 1. Digunakan untuk mendefinisikan karakteristik dari record (meliputi nama, tipe dan lebar dari field). 2. Untuk menentukan kunci field. 3. Menyediakan cara untuk menentukan hubungan dengan data di file lain. 4. Untuk merubah struktur dari record. 5. Untuk menampilkan struktur dari record. DDL menurut Whitten (2000, p477) digunakan oleh DBMS untuk secara fisikal menetapkan tipe record, field dan struktural relationship. Pada umumnya, DDL menjelaskan view dari database. View membatasi porsi dari database yang akan digunakan atau diakses oleh user dan program lain.
2.1.4
Data Manipulation Language (DML) Pengertian dari Data Manipulation Language (DML) berdasarkan
Connolly (2002, p41) yaitu bahasa yang menyediakan kumpulan operasi untuk mendukung operasi manipulasi data pada database. Operasinya biasanya adalah o Pemasukkan data baru dalam database o Modifikasi data yang telah disimpan dalam database o Pencarian dan pengembalian data yang terdapat dalam database o Penghapusan data dari database Data Manipulation Language (DML) menurut Hartono (1999, p739) digunakan untuk memanipulasi database yang telah didefinisikan dengan DDL.
14 DML berdasarkan Whitten (2000, p478) digunakan untuk membuat, membaca, meng-update dan menghapus record pada database dan untuk menavigasi antara record yang berbeda dan tipe dari record yang berbeda. DBMS dan DML menyembunyikan detail yang menyangkut bagaimana record diatur dan dialokasikan dalam disk. Ada 2 type dari DML (Connolly, 2002, p41) berdasarkan konstruksi retrieval (pengembalian data) yaitu procedural dan non-procedural. Yang dimaksud dengan procedural DML adalah bahasa yang membolehkan user untuk memberitahu sistem tentang data apa yang dibutuhkan dan bagaimana cara untuk mengembalikan data, sedangkan non-procedural DML adalah bahasa yang membolehkan user untuk menentukan data apa yang dibutuhkan daripada bagaimana
data
itu
dikembalikan.
Secara
tipikal,
bahasa
procedural
menoperasikan record secara individual, sedangkan non-procedural beroperasi pada kumpulan record.
2.1.5
Normalisasi Pengertian Normalisasi menurut Connolly (2002, p376) adalah teknik
untuk memproduksi kumpulan relasi dengan properties yang sesuai, yang memberikan kebutuhan data (data requirement) dalam perusahaan. Tujuan
utama
dari
design
relational
database
adalah
untuk
mengumpulkan atribut ke dalam relasi untuk mengurangi data redudancy dan mengurangi ruang penyimpanan file yang diperlukan. Relasi yang memiliki data berulang atau redundant data dapat meyebabkan masalah yang dikenal dengan
15 nama update anomaly. Berikut adalah macam dari update anomaly. Untuk mempermudah pengertian, dapat dilihat dari contoh tabel berikut.
Tabel 2.1 Tabel Staff dan Branch (sumber: Connolly (2002, p377)) Staff staffNo
Sname
Position
Salary
branchNo
SL21
John White
Manager
30000
B005
SG37
Ann Beech
Assistant
12000
B003
SG14
David Ford
Supervisor
18000
B003
SA9
Mary Howe
Assistant
9000
B007
SG5
Susan Brand
Manager
24000
B003
SL41
Julie Lee
Assistant
9000
B005
Branch BranchNo Baddress B005
22 Deer Rd, London
B007
16 Argyll St, Aberdeen
B003
163 Main St, Glasgow
Tabel 2.2 Tabel StaffBranch (sumber: Connolly (2002, p377)) StaffBranch staffNo
Sname
Position
Salary
branchNo
bAddress
SL21
John White
Manager
30000
B005
22 Deer Rd, London
SG37
Ann Beech
Assistant
12000
B003
163 Main St, Glasgow
SG14
David Ford
Supervisor
18000
B003
163 Main St, Glasgow
SA9
Mary Howe
Assistant
9000
B007
16 Argyll St, Aberdeen
SG5
Susan Brand
Manager
24000
B003
163 Main St, Glasgow
SL41
Julie Lee
Assistant
9000
B005
22 Deer Rd, London
16 o Insertion anomaly Ada dua tipe utama dari insertion anomaly: -
untuk memasukkan detail dari member baru staff ke dalam StaffBranch, detail dari cabang dimana staff ditempatkan juga harus dimasukkan. Contoh data baru dari staff yang berlokasi di cabang B007. Detail dari nomor cabang B007 yang tepat harus dimasukkan agar konsisten dengan nilai cabang B007 pada relasi StaffBranch. Untuk mengatasinya adalah pada tabel 2.1 dengan memisahkan tabel StaffBranch menjadi tabel Staff dan tabel Branch agar tidak terjadi inkonsistensi.
-
Untuk memasukkan detail dari cabang baru yang belum memiliki staff, maka pada tabel StaffBranch data tentang staffnya berisi null. Sedangkan staffNo adalah primary key untuk StaffBranch, apabila diisi dengan null maka ini melanggar aturan integritas entity (dalam sebuah relasi tidak ada atribut dari primary key yang null). Tabel 2.1 mencegah masalah ini karena detail cabang dimasukkan pada tabel Branch secara terpisah dari detail staff.
o Deletion anomaly Jika menghapus record pada StaffBranch tentang staff yang paling akhir yang ditempatkan di cabang, maka detail tentang cabang juga akan terhapus. Contoh, jika menghapus record nomor staff SA9 dari table StaffBranch, detail yang berkaitan dengan nomor cabang B007 akan hilang dari database. Tabel 2.1 mencegah masalah diatas karena record
17 cabang disimpan terpisah dengan record staff. Maka apabila detail staff SA9 dihapus, Detail cabang B007 tidak terpengaruh. o Modification anomaly Jika mau dilakukan perubahan nilai salah satu atribut cabang dari tabel StaffBranch, contoh alamat dari cabang B003, maka harus mengubah seluruh data yang memiliki nomor cabang B003. Jika modifikasi ini tidak merubah semua record yang berkaitan maka database akan menjadi tidak konsisten.
2.1.5.1 Proses Normalisasi Normalisasi (Connolly, 2002, p386) adalah sebuah teknik formal untuk menganalisa relasi berdasarkan pada kunci primer (atau kunci kandidat) dan functional dependency. Teknik yang dimaksud terdiri dari serangkaian aturan yang bisa digunakan untuk mengecek relasi individu sehingga database dapat dinormalisasi ke tingkat tertentu. Mulai dari sebuah tabel dalam kategori tidak normal (unnormal form atau UNF) secara bertahap diubah ke bentuk normal pertama (first normal form atau 1NF), kemudian dari tabel dalam bentuk 1NF diubah lagi menjadi bentuk normal kedua (second normal form atau 2NF), selanjutnya diubah ke dalam bentuk normal ketiga (third normal form atau 3NF), Boyce Codd Normal Form (BCNF), bentuk normal keempat (fourth normal form atau 4NF), dan bentuk normal kelima (fifth normal form atau 5NF).
18 o Unnomal Form – UNF Tabel 2.3 Tabel ClientRental UNF (sumber : Connolly (2002, p389)) ClientRental clientNo
cName
propertyNo
pAddress
rentStart
rentFinish
rent
ownerNo
oName
CR76
John
PG4
6 Lawrence
1-Jul-00
31-Aug-01
350
CO40
Tina
Kay
St, Glasgow PG16
5 Novar Dr,
Murphy 1-Sep-01
1-Sep-02
450
CO93
Glasgow CR56
Aline
PG4
Stewart
6 Lawrence
Shaw 1-Sep-99
10-June-00
350
CO40
St, Glasgow PG36
2 Manor Rd, 5 Novar Dr,
10-Oct-00
1-Dec-01
375
CO93
Tony Shaw
1-Nov-02
10-Aug-03
450
CO93
Glasgow
Sebuah tabel berada dalam bentuk belum normal apabila terdapat satu atau lebih atribut yang menampung banyak nilai atau informasi berulang (repeating group). Untuk merubah tabel yang belum normal menjadi tabel bentuk 1NF, maka perlu identifikasi dan menghilangkan informasi berulang dari tabel tersebut (Connolly, 2002, p388). Tabel 2.3 menunjukkan tabel UNF. Ada beberapa kolom yang bernilai banyak (multivalued) dan identifikasi baris-baris tabel tersebut cukup dengan kolom clientNo. Ada 2 pendekatan yang dapat dilakukan untuk menghilangkan informasi berulang dari tabel yang belum normal, yaitu: -
Tina Murphy
Glasgow PG16
Tony
Menghilangkan informasi berulang dengan memasukkan data yang bersangkutan ke dalam kolom kosong dari baris yang memiliki
Tony Shaw
19 informasi berulang. Dengan kata lain, kolom tersebut diisi dengan menduplikasi data yang tidak berulang. Contoh pendekatan ini bisa dilihat pada Tabel 2.4. -
Menghilangkan informasi berulang dengan menempatkan data yang berulang bersama dengan copy dari kunci atribut asli, dalam relasi yang terpisah.
o First Normal Form – 1NF
Tabel 2.4 Tabel ClientRental 1NF (sumber : Connolly (2002, p390)) ClientRental clientNo
propertyNo
cName
pAddress
rentStart
rentFinish
rent
ownerNo
oName
CR76
PG4
John
6 Lawrence
1-Jul-00
31-Aug-01
350
CO40
Tina
Kay
St, Glasgow
John
5 Novar Dr,
Kay
Glasgow
Aline
6 Lawrence
Stewart
St, Glasgow
Aline
2 Manor Rd,
Stewart
Glasgow
Aline
5 Novar Dr,
Stewart
Glasgow
CR76 CR56 CR56 CR56
PG16 PG4 PG36 PG16
Murphy 1-Sep-01
1-Sep-02
450
CO93
Tony Shaw
1-Sep-99
10-June-00
350
CO40
Tina Murphy
10-Oct-00
1-Dec-01
375
CO93
Tony Shaw
1-Nov-02
10-Aug-03
450
CO93
Sebuah tabel dikatakan pada bentuk 1NF apabila (Connolly, 2002, p388) dalam relasi semua irisan dari tiap kolom dan baris terdiri dari satu dan hanya satu nilai saja. Setelah pendekatan-pendekatan yang bisa dilakukan untuk merubah tabel UNF mejadi 1NF, maka dilakukan normalisasi yaitu dengan cara menghilangkan unsur pengulangan (repeating).
Tony Shaw
20 Penghilangan unsur nilai banyak (multivalued atau repeating) tersebut membawa konsekuensi pada susunan baris-baris tabel, konsekuensinya adalah primary key tabel yang bersangkutan harus direvisi. Pada gambar 2.4 dari tabel, primary key nya menjadi clientNo dan propertyNo. Maka tabel ClientRental sudah dalam bentuk 1NF yang terdiri dari nilai tunggal pada irisan tiap kolom dan barisnya. o Second Normal Form – 2NF Suatu tabel mencapai tingkat normal kedua (2NF) jika tabel tersebut sudah pada tahap 1NF dan semua atribut bukan kunci tabel bersangkutan tergantung sepenuhnya pada primary key (Connolly, 2002, p392). Bila suatu tabel terdapat atribut bukan kunci (minimal satu) tergantung hanya ada sebagian atribut primary key dinamakan partial dependency, itu berarti tabel tersebut belum memenuhi 2NF. Untuk memahami akan ketergantungan yang ada maka perlu dimengerti tentang functional dependency, yang mana menjelaskan hubungan antar atribut. Pada Tabel 2.4 Tabel Client Rental, dapat dilihat functional dependency nya:
Fd1 clientNo, propertyNo → rentStart, rentFinish
(Primary key)
Fd2 clientNo → cName
(Partial dependency)
Fd3 propertyNo → pAddress, rent, ownerNo, oName
(Partial dependency)
Fd4 ownerNo → oName
(Transitive dependency)
Fd5 clientNo, rentStart → propertyNo, pAddress, rentFinish, rent, ownerNo,oName
(Candidate key)
Fd6 propertyNo, rentStart → clientNo, cName, rentFinish
(Candidate key)
21 Dari functional dependency di atas dapat dilihat bahwa terdapat partial dependency dan transitive dependency. Transitive dependency dapat dihilangkan dengan normalisasi bentuk 3NF, sedangkan adanya partial dependency dapat dihilangkan dengan normalisasi 2NF. Maka relasi yang terjadi dapat dilihat pada Tabel 2.5 Tabel 2NF.
Tabel 2.5 Tabel 2NF (sumber: Connolly (2002, p393)) Client clientNo
cName
CR76
John Kay
CR56
Aline Stewart
Rental clientNo
propertyNo
rentStart
RentFinish
CR76
PG4
1-Jul-00
31-Aug-01
CR76
PG16
1-Sep-01
1-Sep-02
CR56
PG4
1-Sep-99
10-June-00
CR56
PG36
10-Oct-00
1-Dec-01
CR56
PG16
1-Nov-02
10-Aug-03
PropertyOwner PropertyNo
pAddress
Rent
ownerNo
oName
PG4
6 Lawrence St, Glasgow
350
CO40
Tina
PG16
5 Novar Dr, Glasgow
450
CO93
Murphy
PG36
2 Manor Rd, Glasgow
375
CO93
Tony Shaw Tony Shaw
o Third Normal Form – 3NF Sebuah tabel dikatakan telah memenuhi 3NF (Connolly, 2002, p394) jika tabel yang bersangkutan telah memenuhi 2NF, serta atribut
22 bukan kunci tidak memiliki unsur ketergantungan transitif (transitive dependency) terhadap primary key. Yang dimaksud dengan ketergantungan transitif adalah jika ada kondisi dimana A, B dan C atribut dari tabel yang memiliki hubungan A → B dan B → C, maka C secara transitif tergantung pada A melalui B. Dari Tabel 2.5 Tabel 2NF dapat ditarik functional dependency yang mengandung transitive dependency yaitu pada : PropertyOwner PropertyNo → pAddress, rent, ownerNo, oName
(Primary key)
ownerNo → oName
(Transitive dependency)
Untuk menghilangkan transitive dependency maka dilakukan normalisasi 3NF yang akan menghasilkan relasi baru yang dapat dilihat dari gambar tabel dibawah ini.
Tabel 2.6 Tabel 3NF dari PropertyOwner (sumber: Connolly (2002, p395)) PropertyForRent PropertyNo
pAddress
Rent
ownerNo
PG4
6 Lawrence St, Glasgow
350
CO40
PG16
5 Novar Dr, Glasgow
450
CO93
PG36
2 Manor Rd, Glasgow
375
CO93
Owner ownerNo
oName
CO40
Tina Murphy
CO93
Tony Shaw
23 Hasil yang lebih lengkapnya dapat dilihat pada tabel berikut.
Tabel 2.7 Tabel lengkap 3NF dari ClientRental (sumber: Connolly (2002, p396)) Client clientNo
cName
CR76
John Kay
CR56
Aline Stewart
Rental clientNo
propertyNo
rentStart
RentFinish
CR76
PG4
1-Jul-00
31-Aug-01
CR76
PG16
1-Sep-01
1-Sep-02
CR56
PG4
1-Sep-99
10-June-00
CR56
PG36
10-Oct-00
1-Dec-01
CR56
PG16
1-Nov-02
10-Aug-03
PropertyForRent PropertyNo
pAddress
Rent
ownerNo
PG4
6 Lawrence St, Glasgow
350
CO40
PG16
5 Novar Dr, Glasgow
450
CO93
PG36
2 Manor Rd, Glasgow
375
CO93
Owner ownerNo
oName
CO40
Tina Murphy
CO93
Tony Shaw
o Boyce Codd Normal Form – BCNF Relasi database didesign agar tidak terdapat partial dependency ataupun transitive dependency, karena ketergantungan ini menimbulkan update anomaly. Tabel-tabel dalam pembahasan normalisasi hingga
24 bentuk 3NF berhubungan dengan kunci kandidat (candidate key) tunggal, namun tidak jarang sebuah tabel memiliki lebih dari satu kunci kandidat, oleh sebab itu definisi pada 3NF perlu diperkuat. Sebuah tabel berada pada kasus BCNF jika tabel tersebut memiliki dua atau lebih kunci kandidat, kunci-kunci kandidat tersebut berupa komposisi dan mereka beririsan (overlapped) setidaknya pada sebuah atribut. Untuk lebih jelasnya perhatikan contoh tabel berikut ini.
Tabel 2.8 Tabel ClientInterview (sumber: Connolly (2002, p399)) ClientInterview clientNo
interviewDate
interviewTime
staffNo
roomNo
CR76
13-May-02
10.30
SG5
G101
CR56
13-May-02
12.00
SG5
G101
CR74
13-May-02
12.00
SG37
G102
CR56
1-Jul-02
10.30
SG5
G102
Dari tabel diatas, berikut ini adalah functional dependencynya. Fd1
clientNo, interviewDate → interviewTime, staffNo, roomNo
(Primary key)
Fd2
staffNo, interviewDate, interviewTime → clientNo
(Candidate key)
Fd3
roomNo, interviewDate, interviewTime → staffNo, clientNo
Fd4
(Candidate key)
staffNo, interviewDate → roomNo
Dari functional dependency diatas yang perlu dibahas adalah (staffNo, interviewDate) → roomNo (direpresentasikan sebagai Fd4). Walaupun (staffNo, interviewDate) bukan candidate key untuk tabel
25 ClientInterview, hubungan functional dependency ini adalah 3NF. Karena adanya determinant (staffNo, interviewDate) yang mana bukan candidate key pada relasi, maka supaya tidak terjadi update anomaly perlu dilakukan normalisasi BCNF. Berikut tabel hasil normalisasinya.
Tabel 2.9 Tabel Interview dan StaffRoom BCNF (sumber: Connolly (2002, p400)) Interview clientNo
interviewDate
interviewTime
staffNo
CR76
13-May-02
10.30
SG5
CR56
13-May-02
12.00
SG5
CR74
13-May-02
12.00
SG37
CR56
1-Jul-02
10.30
SG5
staffNo
interviewDate
roomNo
SG5
13-May-02
G101
SG37
13-May-02
G102
SG5
1-Jul-02
G102
StaffRoom
o Fourth Normal Form – 4NF Meski sebuah tabel telah mencapai normal BCNF, namun masih mungkin terjadi kesulitan berkenaan dengan adanya informasi berulang yang disebut sebagai multi-valued. Sehubungan dengan hal tersebut maka diperkenalkan suatu konsep yang dinamakan ketergantungan nilai jamak (Multi-Valued Dependency – MVD). Multi-Valued
Dependency
(Connolly,
2002,
p407)
merepresentasikan ketergantungan antar atribut (contohnya A, B dan C)
26 dalam sebuah relasi, dalam hal ini tiap nilai A mempunyai kumpulan nilai B dan kumpulan nilai untuk C. Tetapi kumpulam nilai untuk B dan C tidak tergantung satu sama lain. Definisi dari fourth normal form (4NF) (Connolly, 2002, p408) adalah sebuah relasi dalam Boyce Codd normal form dan terdiri dari nontrivial multi-valued dependency. 4NF adalah bentuk normal yang lebih kuat dari BCNF dalam hal menjaga relasi dari muatan nontrivial MVD dan data redudancy. o Fifth Normal Form – 5NF Bentuk normal kelima (5NF) disebut juga sebagai bentuk project join normal form (PJNF) karena adanya lossless-join property sehingga tidak bisa me-rejoin hasil relasi untuk menghasilkan relasi asal atau original. Ada beberapa kasus dimana dibutuhkan untuk mendekomposisi relasi menjadi dua atau lebih relasi (Connolly, 2002, p409-410). Yang dimaksud dengan lossless-join dependency adalah sebuah properti dari dekomposisi, yang memastikan tidak ada record atau tuple yang dihasilkan saat relasi sedang digabungkan dengan operasi natural join.
2.1.6
4 GL Sebuah operasi yang membutuhkan ratusan baris dalam third generation
language (3GL), seperti COBOL, secara umum pada 4GL baris yang dibutuhkan lebih sedikit (Connolly, 2002, p42).
27 Dibandingkan dengan 3GL yang procedural, 4GL merupakan nonprocedural : user yang menentukan apa yang akan dilakukan, bukan bagaimana. 4GL memiliki level komponen lebih besar yang dikenal sebagai fourth generation tool. User tidak perlu menentukan langkah-langkah tugas program, tetapi hanya menentukan parameter untuk tool yang digunakan pada program aplikasi. Berikut akan disampaikan tipe dari 4GL. o Forms generator Form generator adalah sebuah fasilitas interaktif untuk membuat pemasukkan data secara cepat dan memperlihatkan tampilan bentuk – bentuk
layar.
Forms
generators
mengijinkan
pengguna
untuk
mendefinisikan bentuk tampilan, informasi yang akan ditampilkan, dan tempat pada layer untuk mendisplay. Dan mengijinkan definisi warna dari elemen layer dan karakteristik lain sperti bold, underline, blinking, reverse video, dan lain – lain. Form generator yang lebih baik mengijinkan kreasi dari atribut asal, dengan menggunakan operator aritmetika atau agregasi dan spesifikasi pemeriksaan validasi untuk pemasukkan data. o Report generator Report generator adalah faslisitas untuk membuat laporan – laporan dari data yang disimpan dalam database. Sama seperti bahasa query yang mengijinkan pengguna untuk bertanya pada database dan menerima informasi dari database untuk laporan. Memiliki kontrol yang lebih baik mengenai tampilan. Report generator dapat secara otomatis
28 menentukan tampilan atau kita bisa membuat tampilan sendiri menggunakan instruksi perintah – perintah report- generator khusus. Ada dua tipe utama dari report generator: language-oriented dan visually-oriented. Pada kasus pertama, kita memasukkan perintah dengan sublanguage untuk mendefinisikan data apa saja yang harus dimasukkan pada laporan dan bagaimana laporan ditampilkan. Pada kasus kedua, kita menggunakan fasilitas yang mirip dengan form generator untuk mendefinisikan informasi yang sama. o Graphics generator Graphic generator adalah fasilitas untuk mengambil data dari database
dan
menampilkan
data
dalam
bentuk
grafik
yang
memperlihatkan trends dan hubungan - hubungan dalam data. Maksudnya, mengijinkan pengguna untuk membuat grafik bar, grafik pie, grafik batang, grafik pencar, dan lain – lain. o Application generator Application generator adalah fasilitas untuk menghasilkan program yang berhubungan dengan database. Penggunaan application generator bisa mengurangi waktu yang dibutuhkan untuk merancang seluruh aplikasi perangkat lunak. Biasanya terdiri dari modul – modul pre-written yang membandingkan fungsi – fungsi dasar yang sering digunakan program. Modul – modul ini biasanya ditulis pada level bahasa tingkat tinggi, terdapat perpusatakaan fungsi – fungsi. Pengguna memspesifikasikan tugas program; application generator menentukan bagaimana tugas dilaksanakan.
29 2.1.7
Siklus Hidup Aplikasi Database Sistem database (Connolly, 2002, p271) adalah komponen dasar dari
sistem informasi organisasi besar. Maka, daur hidup aplikasi database biasanya berasosiasi dengan daur hidup sistem informasi. Tahapan dari daur hidup aplikasi database ditunjukkan pada gambar dibawah. Penting untuk mengenali bahwa tahapan – tahapan dari daur hidup aplikasi database tidak selalu sekuensial, tetapi meliputi sejumlah perulangan dari tahapan sebelumnya melalui feed back loops. Misalnya, masalah yang terjadi
selama
merancang
database
mungkin
memerlukan
tambahan
pengoleksian dan analisis kebutuhan. Untuk aplikasi database yang kecil, dengan sedikit pengguna, daur hidup tidak perlu terlalu rumit. Untuk merancang aplikasi database medium hingga besar dengan sepuluh sampai seribu pengguna, menggunakan ratusan queries dan program aplikasi, daur hidup bisa menjadi sangat rumit.
30 Database planning System definition
Requirement collection and analysis
DBMS selection (optional)
Database design Conceptual Database design Application design
Logical Database design Physical Database design
Prototyping (optional)
Implementation
Data convertion and loading Testing
Operational maintenance
Gambar 2.1 Tahapan database application life cycle (sumber: Connolly (2002, p272))
31 Tabel 2.10 Rangkuman aktivitas utama tiap tahapan (sumber : Connolly (2002, p273)) Tahapan
Aktivitas Utama
Database planning
Merencanakan agar tahapan daur hidup bisa direalisasikan secara efisien dan efektif
System definition
Menspesifikasikan batasan aplikasi database, penggunaannya dan area aplikasi
Requirement collection and
Pengoleksian dan menganalisa kebutuhan user
analysis
dan area aplikasi
Database design
Design konseptual, logikal, dan fisikal database
DBMS selection (optional)
Memilih DBMS yang sesuai dengan aplikasi database
Application design
Merancang user interface dan program aplikasi yang digunakan dan memproses database
Prototyping (optional)
Membangun model kerja aplikasi database, yang mengijinkan perancang atau pengguna untuk memvisualisasikan dan mengevaluasi bagaimana sistem final akan terlihat dan fungsinya
Implementation
Membuat definisi eksternal, konseptual, dan internal database dan program aplikasi
Data conversion and loading
Mengambil data dari sistem lama ke sistem baru
Testing
Apilkasi database dites untuk error dan divalidasikan sesuai dengan kebutuhan yang dispesifikasikan oleh pengguna
Operational maintenance
Aplikasi database diimplementasikan. Sistem dimonitor secara terus – menerus dan dirawat. Ketika dibutuhkan, kebutuhan baru dimasukkan ke aplikasi database melalui tahapan – tahapan daur hidup
32 2.1.8
Design Konseptual, Logikal dan Fisikal Design konseptual, logikal dan fisikal merupakan tahapan utama dalam
proses design methodology. Yang dimaksud dengan design methodology (Connolly, 2002, p418) adalah pendekatan terstruktur yang menggunakan prosedur, teknik, tool dan tambahan dokumentasi untuk mendukung dan memfasilitasi proses design.
2.1.8.1 Design Konseptual Perancangan Konseptual Database (Connolly, 2002, p419) adalah proses pembangunan model informasi yang digunakan dalam perusahaan, terlepas dari semua pertimbangan fisik, misalnya DBMS pilihan, program aplikasi, bahasa pemrograman, perangkat keras, tampilan. Tujuan dari fase perancangan konseptual database adalah untuk membangun representasi konseptual dari database, termasuk identifikasi dari entities, relationship, dan atribut yang penting. Dalam design konseptual ada tahap-tahap yang harus diperhatikan yaitu Step 1 Membangun model data konseptual lokal untuk setiap tujuan Tujuan : membangun model data konseptual lokal perusahaan untuk setiap tujuan khusus Step 1.1 Identifikasi tipe – tipe entity Tujuan : mengidentifikasi tipe – tipe entity utama yang dibutuhkan. Dari tahap ini akan dihasilkan data dictionary tentang nama entity, deskripsinya, nama lain dari entity dan occurence (keterangan).
33 Step 1.2 Identifikasi tipe – tipe relationship Tujuan : mengidentifikasi relationship penting yang ada diantara tipe – tipe entity. Data dictionary yang dihasilkan berupa nama entity, multiplicity, dan hubungan dengan entity lain. Step 1.3 Identifikasi dan menghubungkan atribut – atribut dengan tipe entity dan relationship Tujuan : Mengasosiasikan atribut – atribut dengan tipe – tipe entity atau relationship yang sesuai. Data dictionary dari tahap ini menampilkan nama entity, atributnya, keterangan dari atribut, tipe data dan panjang atribut, null dan multivalued. Step 1.4 Membangun domain atribut Tujuan : membangun domain – domain untuk atribut pada model data konseptual lokal. Step 1.5 Membangun kandidat dan atribut primary key Tujuan : Mengidentifikasi candidate keys untuk tiap tipe entity dan kalau ada lebih dari satu, pilih salah satu untuk menjadi primary key. Step 1.6 Mempertimbangkan penggunaan konsep enhance modeling (optional) Tujuan : Mempertimbangkan penggunaan konsep enhance modeling, misalnya spesialisasi atau generalisasi, agregasi, dan komposisi.
34 Step 1.7 Memeriksa model dari perulangan data (redundancy) Tujuan : memeriksa model dari segala bentuk perulangan (redundancy). Ada dua aktivitas pada tahap ini yaitu menganalisa kembali one-to-one relationship dan menghilangkan relationship berulang. Step 1.8 Validasi model konseptual lokal untuk transaksi pengguna Tujuan : memastikan bahwa model konseptual lokal mendukung transaksi yang dibutuhkan sesuai view. Step 1.9 Meninjau kembali model data konseptual dengan pengguna Tujuan : meninjau kembali model data konseptual dengan pengguna
untuk
memastikan
bahwa
model
merupakan
representasi asli dari tujuan.
2.1.8.2 Design Logikal Pengertian logical database design menurut Connolly (2002, p441) adalah proses pembuatan model dari informasi yang digunakan dalam perusahaan berdasarkan data model spesifik, tetapi bebas dari DBMS tertentu dan pertimbangan fisikal lainnya. Perancangan metodologi terdiri dari fase – fase yang masing – masing terdiri dari sejumlah langkah, yang menuntun perancang dengan memakai tehnik yang sesuai pada setiap tahapan proyek. Juga membantu
35 perancang untuk menrencanakan, mengontrol, dan mengevaluasi proyek pembangunan database. Dalam design logikal ada 2 tahap penting yaitu Step 2 membangun dan memvalidasi data model logikal untuk tiap view Tujuannya adalah membangun data model logikal lokal dari data model konseptual lokal merepresentasikan pandangan tertentu dari perusahaan dan kemudian memvalidasi model ini untuk memastikan kebenaran secara struktural dan memastikan mendukung transaksi yang dibutuhkan. Step 3 membangun dan memvalidasi data model logikal global Tujuannya yaitu untuk menggabungkan data model logikal lokal individu menjadi satu data model logikal global yang merepresentasikan perusahaan. Tahapan
tersebut
masih
terdiri
dari
langkah-langkah
pembuatannya. Berikut akan dijelaskan dari langkah-langkah tiap tahapan dalam design logikal. Step 2.1 Menghilangkan feature yang tidak kompatible dengan model relasional (langkah optional) Tujuannya adalah untuk meningkatkan data model konseptual lokal untuk menghilangkan feature yang tidak kompatible dengan model relasional. Hal ini dapat dilakukan dengan cara menghilangkan
tipe
hubungan
binary
many
to
many,
menghilangkan tipe hubungan recursive many to many, menghilangkan tipe hubungan kompleks, menghilangkan atribut multivalued.
36 Step 2.2 Membuat relasi untuk data model logikal lokal Tujuannya untuk membuat relasi data model logikal lokal untuk merepresentasikan entity, relationship dan atribut yang sudah diidentifikasi. Step 2.3 Memvalidasi relasi menggunakan normalisasi Tujuannya untuk memvalidasi relasi dalam data model logikal lokal dengan menggunakan teknik normalisasi. Penjelasan tentang normalisasi dapat dilihat pada bahasan 2.1.5 Normalisasi. Step 2.4 Memvalidasi relasi berdasarkan transaksi user Tujuannya untuk memastikan bahwa relasi dalam data model logikal lokal mendukung transaksi yang dibutuhkan
view,
sebagai detail dalam user requirement specification. Step 2.5 Menentukan intregrity constraint Tujuannya untuk menentukan integrity constraint yang diberikan dalam view. Ada 5 jenis integrity constraint yang patut dipertimbangkan yaitu data yang dibutuhkan, attribute domain constraint, entity integrity, referential integrity dan enterprise constraint. Step 2.6 Mereview data model logikal lokal dengan user Tujuannya untuk memastikan data model logikal lokal dan dokumentasi
dukungan
yang
menjelaskan
model,
adalah
representasi yang sesungguhnya dari view. Step 3.1 Menggabungkan data model logikal lokal ke dalam model global
37 Tujuannya untuk menggabungkan data model logikal lokal menjadi satu data model logikal global dari perusahaan. Sampai pada point ini, untuk tiap data model logikal lokal telah ada diagram ER, skema relasi, data dictionary dan dokumentasi yang mendukung. Semua ini digunakan untuk mengidentifikasi persamaan dan perbedaan antar model dan kemudian membantu menggabungkan model-model itu. Step 3.2 Memvalidasi data model logikal global Tujuannya untuk memvalidasi relasi yang dibuat dari data model logikal global yang menggunakan normalisasi dan untuk memastikan relasi tersebut mendukung transaksi yang dibutuhkan, jika perlu. Step 3.3 Memeriksa pertumbuhan yang akan datang Tujuannya untuk mengontrol apakah terjadi perubahan significant dalam masa yang akan datang dan untuk mengkalkulasi apakah data model logikal global dapat menyediakan tempat untuk perubahan ini. Step 3.4 Mereview data model logikal global dengan user Tujuannya adalah untuk memastikan bahwa data model logikal global merupakan representasi yang benar dari perusahaan.
2.1.8.3 Design Fisikal Perancangan Fisikal Database (Connolly, 2002, p478) adalah proses memproduksi deskripsi implementasi dari database pada
38 secondary storage. Menjelaskan relasi dasar, file organisasi – organisasi dan index – index yang digunakan untuk mendapatkan akses efisien ke data dan integrity constraint yang berhubungan dan pendekatan keamanan. Salah satu tujuan utama dari design fisikal database adalah untuk menyimpan data dalam cara yang hemat dan tepat. Faktor-faktor yang mempengaruhi nya adalah hasil transaksi, waktu respon dan disk storage. Berikut adalah tahapan dari design fisikal database. Step 4 Menerjemahkan model data logikal global untuk DBMS pilihan Tujuannya untuk menghasilkan skema database relasional dari data model logikal global yang dapat diimplementasikan dalam DBMS target. Step 4.1 Merancang relasi dasar Tujuannya untuk menentukan cara merepresentasikan relasi dasar yang diidentifikasikan dalam data model logikal global pada DBMS target. Step 4.2 Merancang representasi dari data yang didapat Tujuannya untuk memutuskan cara merepresentasikan derived data yang muncul dalam data modal logikal global pada DBMS target. Atribut yang nilainya dapat dicari dengan meneliti nilai dari atribut lain dikenal sebagai derived atau calculated attribute. Step 4.3 Merancang enterprise constraint Tujuannya untuk mendesign enterprise constraint untuk DBMS target.
39 Step 5 Merancang representasi fisikal Tujuannya untuk menentukan organisasi file optimal untuk menyimpan relasi dasar dan peng-index-an yang dibutuhkan untuk memperoleh perfoma baik, yaitu, dimana semua relasi dan tuple akan ditaruh pada secondary storage. Step 5.1 Analisa transaksi Tujuannya untuk memahami fungsionalitas dari transaksi yang akan berjalan pada database dan untuk menganalisa transaksi penting. Dalam menganalisa transaksi, diperlukan adanya identifikasi kriteria perfoma seperti transaksi yang berjalan berkala dan memiliki dampak significant pada perfoma, transaksi yang penting untuk operasi bisnis, dan waktu selama per hari atau per minggu yang akan mempunyai permintaan tertinggi untuk database. Step 5.2 Memilih file organisasi – organisasi Tujuannya untuk menentukan organisasi file dengan tepat untuk tiap relasi dasar. Untuk memahami organisasi file dan peng-indexan maka perlu dimengerti tentang cara pemilihan organisasi file, misal dengan heap (pemilihan secara tidak berurut). Step 5.3 Memilih index – index Tujuannya untuk menentukan apakah dengan penambahan index akan meningkatkan perfoma dari sistem.
40 Step 5.4 Memperkirakan kebutuhan ruang penyimpanan Tujuannya untuk memperkirakan jumlah ruang disk yang akan dibutuhkan oleh database. Step 6 Merancang user views Tujuannya untuk mendesign user view yang diidentifikasi selama pengumpulan kebutuhan dan tahap analisis dari daur hidup aplikasi database relasional. Step 7 Merancang mekanisme keamanan Tujuannya untuk mendesign mekanisme keamanan untuk database yang dispesifikasikan
oleh
user.
DBMS
relasional
pada
umumnya
menyediakan 2 tipe keamanan database yaitu keamanan sistem (system security) dan keamana data (data security). Step 8 Mempertimbangkan
pengenalan
pengontrolan
redundancy
(perulangan) Tujuannya untuk menentukan apakah pengenalan redudancy pada aturan pengontrolan dengan tidak menggunakan aturan normalisasi akan meningkatkan perfoma dari sistem. Pada intinya di tahap ini dilakukan proses denormalisasi dengan langkah-langkah sebagai berikut: -
menggabungkan one-to-one relationship.
-
menduplikasi atribut bukan kunci pada one-to-many relationship untuk mengurangi join.
-
menduplikasi atribut foreign key pada one-to-many relationship untuk mengurangi join.
41 -
menduplikasi atribut pada many-to-many relationship untuk mengurangi join.
-
mengenalkan informasi berulang (repeating group).
-
menggabungan lookup table dengan relasi dasar.
-
membuat tabel ekstrasi.
Step 9 Memonitor dan memantau sistem operasional Tujuannya untuk memonitor sistem operasional dan meningkatkan perfoma dari sistem untuk memperbaiki keputusan design yang kurang tepat atau merefleksikan perubahan kebutuhan.
2.2
Penjualan (Sales) 2.2.1
Kas Kas (Niswonger, p290) meliputi koin, uang kertas, cek, wesel (money
order atau kiriman uang melalui pos yang lazim berbentuk draft bank atau cek bank; hal ini untuk selanjutnya kita istilahkan dengan wesel saja), dan uang yang disimpan di bank yang dapat ditarik tanpa pembatasan dari bank bersangkutan. Lazimnya, kas dapat diartikan sebagai segala sesuatu yang diterima bank untuk disetorkan ke rekening bank. Misalnya, cek yang diterima bank untuk disetorkan. Kas menurut Khan (2002, p2.6) adalah the most liquid current asset, termasuk kas di tangan dan kas yang ada di bank. Kas menyediakan likuiditas instan dan bisa digunakan untuk obligasi atau mendapatkan asset tanpa ada penundaan.
42 2.2.2
Kredit Perdagangan secara kredit (Khan, 2002, p2.7) merepresentasikan pihak
luar yang menjual barang ke perusahaan secara kredit untuk jangka pendek tergantung pada praktek dagang. Biasanya kredit seperti ini tidak aman. Salah satu bentuk dari tipe kredit jangka pendek (current liability) yaitu pembeli akan membayar setelah jangka waktu tertentu tapi tidak ada perjanjian tertulis yang formal tentang hal tersebut. Tipe ini disebut juga sebagai account payable. Saat klaim atas barang atau jasa nya tercatat dalam bentuk bon (ada tanda bukti maka disebut sebagai bill / note payable. Bon tersebut merupakan janji pembayaran atas sejumlah uang pada tanggal tertentu.
2.3
Persediaan (Inventory) Persediaan menurut Niswonger (1999, p358) digunakan untuk mengindikasikan
(1) barang dagang yang disimpan untuk kemudian dijual dalam operasi normal perusahaan dan (2) bahan yang terdapat dalam proses produksi atau yang disimpan untuk tujuan itu. Berapa biaya atau harga pokok yang harus dimasukkan dalam persediaan? Harga pokok barang dagang adalah harga beli dikurangi diskon pembelian (jika ada). Biaya – biaya ini merupakan bagian terbesar dari biaya persediaan. Persediaan barang dagang juga mengandung biaya – biaya lain seperti transportasi, cukai impor, dan biaya asuransi atas kehilangan dalam perjalanan.
43 (Niswonger, 1999, p361) Barang dagangan apa saja yang harus dimasukkan dalam persediaan? Semua barang dagang yang dimiliki oleh perusahaan pada tanggal perhitungan harus dimasukkan. Pengertian persediaan berdasarkan Khan (2002, p2.6) berarti penjumlahan dari item yang akan dijual untuk tujuan bisnis biasa (barang jadi), atau dalam proses produksi (work-in-process) atau secara langsung dipakai untuk produk dari barang dan jasa (bahan baku) sampai siap untuk dijual. Yang termasuk dalam inventory adalah bahan baku (raw material), barang setengah jadi (work-in-process/semi-finished), barang jadi (finished good). Setiapnya memberikan tujuan bermanfaat dalam proses produksi dan penjualan. Pengertian barang persediaan atau inventory menurut Indrajit (2003, p3) adalah barang-barang yang biasanya dapat dijumpai di gudang tertutup, lapangan, gudang terbuka, atau tempat-tempat penyimpanan lain, baik berupa bahan baku, barang setengah jadi, barang jadi, barang-barang untuk keperluan operasi atau barang-barang untuk keperluan suatu proyek. Berdasarkan Helfert (2003, p123) tingkat dari inventory tidak bisa dinilai dengan tepat, pendek dari hitungan aktual, verifikasi dan penilaian nilai tertentu. Karena analyst luar dapat sering melalukan ini, maka langkah terbaik untuk selanjutnya ialah untuk menghubungkan nilai inventory yang dicatat dengan penjualan atau untuk biaya dari barang yang terjual, untuk melihat apakah shift relationshipnya over time. Biasanya, inventory rata-rata digunakan untuk membuat kalkulasi ini (rata-rata dari inventory awal dan akhir). Selanjutnya perlu dilakukan pengamatan metode dari pembiayaan inventory oleh perusahaan – seperti last in, first out (LIFO), first in, first out (FIFO), pembiayaan rata-
44 rata – dan tiap perubahan yang dilakukan selama jangka waktu tertentu dikendalikan oleh analysis, karena ini dapat mempengaruhi jumlah di balance sheet secara significant. Inventory bahan baku (Helfert, 2003, p179) bisa diproyeksikan dengan menggunakan pola penarikan dan pembelanjaan bulanan, informasi dimana perusahaan mampu sediakan.
2.4
Piutang (Account Receivable) Istilah piutang (receivable) (Niswonger, 1999, p324) meliputi semua klaim
dalam bentuk uang terhadap entitas lainnya, termasuk individu, perusahaan, atau organisasi lainnya. Piutang ini biasanya memiliki bagian yang signifikan dari total aktiva lancar perusahaan. Transaksi paling umum yang diciptakan piutang adalah pernjualan barang dagang atau jasa secara kredit. Piutang dicatat dengan mendebet akun piutang usaha. Piutang usaha semacam ini normalnya diperkirakan akan tertagih dalam periode waktu yang relative pendek, seperti 30 atau 60 hari. Piutang usaha diklasifikasikan dalam neraca sebagai aktiva lancar. Account Receivable (Khan, 2002, p2.6) merepresentasikan jumlah hutang dari pelanggan ke perusahaan yang timbul dari penjualan barang secara kredit. Analysis account receivable bergantung pada penjualan (Helfert, 2003, p124). Analysis dari account receivable hanya bisa dibuat dengan mempelajari aging dari account individual pada buku perusahaan. Aging termasuk mengklasifikasikan account receiveable ke dalam kolom hari seperti 10 hari, 20 hari, 30 hari, 40 hari dan seterusnya, dan mengaitkan pola ini pada bagian kredit dalam bisnis.
