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
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 bermacam-macam di dalam suatu organisasi.
Definisi database berdasarkan Whitten (2000, p470) adalah koleksi file yang interrelated (berhubungan). Database tidak hanya berupa koleksi file-file. 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.
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
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.
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.
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.
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.
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.
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
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 SG37 SG14 SA9 SG5 SL41 John White Ann Beech David Ford Mary Howe Susan Brand Julie Lee Manager Assistant Supervisor Assistant Manager Assistant 30000 12000 18000 9000 24000 9000 B005 B003 B003 B007 B003 B005 Branch BranchNo Baddress B005 B007 B003 22 Deer Rd, London 16 Argyll St, Aberdeen 163 Main St, Glasgow
Tabel 2.2 Tabel StaffBranch (sumber: Connolly (2002, p377))
StaffBranch
staffNo Sname Position Salary branchNo bAddress SL21 SG37 SG14 SA9 SG5 SL41 John White Ann Beech David Ford Mary Howe Susan Brand Julie Lee Manager Assistant Supervisor Assistant Manager Assistant 30000 12000 18000 9000 24000 9000 B005 B003 B003 B007 B003 B005 22 Deer Rd, London 163 Main St, Glasgow 163 Main St, Glasgow 16 Argyll St, Aberdeen 163 Main St, Glasgow 22 Deer Rd, London
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
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).
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 Kay PG4 PG16 6 Lawrence St, Glasgow 5 Novar Dr, Glasgow 1-Jul-00 1-Sep-01 31-Aug-01 1-Sep-02 350 450 CO40 CO93 Tina Murphy Tony Shaw CR56 Aline Stewart PG4 PG36 PG16 6 Lawrence St, Glasgow 2 Manor Rd, Glasgow 5 Novar Dr, Glasgow 1-Sep-99 10-Oct-00 1-Nov-02 10-June-00 1-Dec-01 10-Aug-03 350 375 450 CO40 CO93 CO93 Tina Murphy Tony Shaw Tony Shaw
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:
- Menghilangkan informasi berulang dengan memasukkan data yang bersangkutan ke dalam kolom kosong dari baris yang memiliki
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 CR76 CR56 CR56 CR56 PG4 PG16 PG4 PG36 PG16 John Kay John Kay Aline Stewart Aline Stewart Aline Stewart 6 Lawrence St, Glasgow 5 Novar Dr, Glasgow 6 Lawrence St, Glasgow 2 Manor Rd, Glasgow 5 Novar Dr, Glasgow 1-Jul-00 1-Sep-01 1-Sep-99 10-Oct-00 1-Nov-02 31-Aug-01 1-Sep-02 10-June-00 1-Dec-01 10-Aug-03 350 450 350 375 450 CO40 CO93 CO40 CO93 CO93 Tina Murphy Tony Shaw Tina Murphy Tony Shaw Tony Shaw
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).
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,
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 CR56 John Kay Aline Stewart Rental
clientNo propertyNo rentStart RentFinish CR76 CR76 CR56 CR56 CR56 PG4 PG16 PG4 PG36 PG16 1-Jul-00 1-Sep-01 1-Sep-99 10-Oct-00 1-Nov-02 31-Aug-01 1-Sep-02 10-June-00 1-Dec-01 10-Aug-03 PropertyOwner
PropertyNo pAddress Rent ownerNo oName PG4 PG16 PG36 6 Lawrence St, Glasgow 5 Novar Dr, Glasgow 2 Manor Rd, Glasgow 350 450 375 CO40 CO93 CO93 Tina Murphy 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
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 PG16 PG36 6 Lawrence St, Glasgow 5 Novar Dr, Glasgow 2 Manor Rd, Glasgow 350 450 375 CO40 CO93 CO93 Owner ownerNo oName CO40 CO93 Tina Murphy Tony Shaw
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 CR56 John Kay Aline Stewart Rental
clientNo propertyNo rentStart RentFinish CR76 CR76 CR56 CR56 CR56 PG4 PG16 PG4 PG36 PG16 1-Jul-00 1-Sep-01 1-Sep-99 10-Oct-00 1-Nov-02 31-Aug-01 1-Sep-02 10-June-00 1-Dec-01 10-Aug-03 PropertyForRent
PropertyNo pAddress Rent ownerNo PG4 PG16 PG36 6 Lawrence St, Glasgow 5 Novar Dr, Glasgow 2 Manor Rd, Glasgow 350 450 375 CO40 CO93 CO93 Owner ownerNo oName CO40 CO93 Tina Murphy 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
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 CR56 CR74 CR56 13-May-02 13-May-02 13-May-02 1-Jul-02 10.30 12.00 12.00 10.30 SG5 SG5 SG37 SG5 G101 G101 G102 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 (Candidate key) Fd4 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
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 CR56 CR74 CR56 13-May-02 13-May-02 13-May-02 1-Jul-02 10.30 12.00 12.00 10.30 SG5 SG5 SG37 SG5 StaffRoom
staffNo interviewDate roomNo SG5 SG37 SG5 13-May-02 13-May-02 1-Jul-02 G101 G102 G102
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)
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).
Dibandingkan dengan 3GL yang procedural, 4GL merupakan non-procedural : 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
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.
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.
Gambar 2.1 Tahapan database application life cycle (sumber: Connolly (2002, p272)) Database design Conceptual Database design Logical Database design Physical Database design Application design DBMS selection (optional) Prototyping (optional) Implementation Data convertion and loading Testing Operational maintenance Requirement
collection and analysis System definition Database planning
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
analysis
Pengoleksian dan menganalisa kebutuhan user 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
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).
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.
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
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.
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
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
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.
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-index-an maka perlu dimengerti tentpeng-index-ang cara pemilihpeng-index-an orgpeng-index-anisasi 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.
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.
- 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.
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.
(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-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.
