6
BAB 2
LANDASAN TEORI
2.1 Teori-teori Database
2.1.1 Pengertian Basis Data
Database system adalah suatu rekord terkomputasi yang tujuannya adalah
menyajikan informasi pada saat dibutuhkan (Date, 1990, p5). Pada sistem basis data
pemakai dapat melakukan manipulasi data dan operasi file, dimulai dari memuat file
baru ke dalam basis data, memasukan data, mengambil data, dan sebagainya. Sistem
basis data dapat diterapkan pada semua komputer, mulai dari komputer mikro (seperti
PC) sampai ke mainframe.
Data base merupakan kumpulan file-file yang saling berelasi, relasi tersebut
biasa ditunjukan dengan kunci dari setiap file yang ada. Satu database menunjukan satu
kumpulan data yang dipakai dalam satu lingkup instansi atau perusahaan. Berikut ini
kegunaan basis data dalam mengatasi permasalahan penyusunan data :
1. Redudansi dan Inkonsistensi data.
2. Kesulitan pengaksesan data.
3. Sekuriti.
4. Multiple User.
5. Indepedansi data (kebebasan data).
Pada umumnya data dalam basis data bersifat integrated dan shared (Date,
1990, p6). Integrated maksudnya adalah basis data merupakan penggabungan beberapa
file data yang berbeda, dengan membatasi pengulangan baik keseluruhan file ataupun
7
sebagian. Shared artinya adalah data individu dalam basis data dapat digunakan secara
bersamaan antara beberapa pengguna yang berbeda.
2.1.2 Database Management System ( DBMS )
Suatu sistem perangkat lunak yang memungkinkan user untuk
mendefinisikan, membuat dan mengatur basis data dan juga menyediakan suatu kontrol
akses ke database ( Connolly, 2002, p16 ).
DBMS adalah suatu perangkat lunak yang berinteraksi dengan program
aplikasi user dan basis data. Biasanya DBMS menyediakan fasilitas sebagai berikut :
• Memungkinkan user untuk menyisipkan, mengupdate, menghapus dan
menerima data dari basis data, biasanya dari Data Manipulation
Language (DML). Sebagai pusat penyimpanan data dan deskripsi data
memudahkan DML untuk menciptakan fasilitas permintaan data
umum, disebut juga query language.
• Memungkinkan user untuk mendefinisikan basis data, biasanya dari
Data Definition Language (DDL). DDL memungkinkan user untuk
membedakan tipe dan struktur data, dan sebagai batasan pada data
untuk disimpan dalam basis data.
2.1.3 Data Definition Language ( DDL )
8
Adalah sebuah deskripsi bahasa yang memungkinkan seorang Database
Administrator (DBA) atau user untuk menjabarkan dan memberi nama suatu entitas
yang dibutuhkan untuk suatu aplikasi dan hubungan yang mungkin berada di antara
entitas-entitas yang berbeda ( Connolly, 2002, p40 ).
Skema basis data berisi tentang beragam definisi yang ditunjukan sebagai arti
dari bahasa khusus yang disebut DDL. DDL digunakan untuk mendefinisikan suatu
skema atau untuk merubah yang sudah ada, tetapi tidak bisa di gunakan untuk
memanipulasi data.
Hasil dari kompilasi DDL adalah berbagai macam tabel yang disimpan secara
kolektif di dalam suatu file khusus yang biasa disebut data dictionary. Data dictionary
diintegrasikan dengan metadata. Metadata ialah data yang medeskripsikan objek di
dalam basis data dan membuat data itu lebih mudah untuk diakses atau dimanipulasi,
metadata mengandung isi dari suatu records, jenis data, dan objek lainnya yang
berkaitan pada user atau yang dibutuhkan oleh DBMS.
Pada tingkat teoritis kita dapat membedakan DDL untuk setiap skema pada
three level architecture, dan sebagian DDL untuk skema external dan juga untuk skema
konseptual, skema internal. Bagaimanapun juga dalam pelaksanaannya DDL
merupakan salah satu spesifikasi yang memungkinkan terdapatnya skema external dan
konseptual.
2.1.4 Data Manipulation Language ( DML )
9
DML adalah suatu bahasa yang menyediakan sekumpulan operasi yang
mendukung suatu basis data untuk memanipulasi operasi pada data yang berada
dalam basis data ( Connolly, 2002, p41 ).
Operasi manipulasi data biasanya termasuk sebagai berikut :
• Menyisipkan suatu data baru kedalam suatu basis data.
• Perubahan data yang disimpan dalam basis data.
• Pencarian kembali data yang terdapat dalam suatu basis data.
• Penghapusan data dari suatu basis data
Untuk itu salah satu dari fungsi utama dari DBMS ialah untuk mendukung
DML dimana pemakai bisa menyusun pernyataan yang bisa memanipulasi data
yang telah dilakukan sebelumnya. Manipulasi data dapat diaplikasi pada tingkat
eksternal dan konseptual sebaik pada tingkat internal. Bagaimanapun juga pada
tingkat internal kita harus mendefinisikan prosedur tingkat rendah yang kompleks
sehingga memungkinkan untuk membuat suatu data akses yang lebih effisien.
Sebagai penjelasannya, pada tingkat yang lebih tinggi menekankan pada
penempatan dari suatu kasus yang akan dibuat, dan usaha yang langsung
disediakan oleh pemakai dengan sistem.
2.1.5 Normalisasi
10
Suatu desain database harus memenuhi kondisi untuk tidak mengandung
anomali, yaitu suatu kejanggalan dari suatu penempatan atribut tertentu dari suatu
obyek data. Untuk membedakan satu rekord denagn yang lainnya maka perlu
dipilih atribut atau kombinasi atribut sebagai kunci primer (primary key) (
Connolly, 2002, p376).
Syarat primary key adalah harus unik, jumlah kombinasi atribut
minimum, dan tidak boleh mengandung nilai kosong (null).
Langkah – langkah normalisasi :
1. Normalisasi Pertama (1ST NF )
Suatu data dikatakan un-normalized, jika di dalamnya mengandung kelompok
berulang ( repeating group ), sehingga untuk membentuk normalisasi pertama (
1st NF ) repeating group harus di hilangkan. Untuk menjadi 1st NF maka group
yang berulang dihilangkan dengan mengisi pada bagian yang kosong dengan data
yang seharusnya pada suatu bentuk record.
2. Normalisasi Kedua ( 2nd NF )
Dapat dihasilkan dengan melihat apakah ada attribut bukan primary key yang
merupakan fungsi dari sebagian primary key (partial dependence ).
Dalam normalisasi kedua ( 2nd NF ) setiap atribut yang tergantung parsial ini
harus dipisahkan dengan mengikut sertakan determinannya. Bentuk normal
diperoleh bila setiap atribut bukan bagian primary key dari suatu tabel
11
sepenuhnya merupakan fungsi (fungsional dependence ) dari primary key
tersebut.
3. Normalisasi Ketiga ( 3rd NF )
Pengujian terhadap 3rd NF dilakukan dengan cara melihat apakah terdapat atribut
bukan key tergantung fungsional terhadap atribut bukan key yang lain ( disebut
ketergantungan transitif atau transitive dependence). Dengan cara yang sama,
maka setiap ketergantungan transitif dipisahkan. 3rd NF sudah cukup bagus dalam
arti bahwa anomali yang dikandungnya sudah sedemikian minimum ( hampir
tidak ada).
2.1.6 4th GL ( Generation Language )
4th GL adalah generasi bahasa tingkat empat. Tidak ada konsensus
tentang apa itu 4th GL, ditujukan untuk bahasa pemrograman yang sederhana
suatu operasi yang membutuhkan banyak baris dalam bahasa generasi tingkat tiga
(3th GL), seperti Cobol, biasanya membutuhkan hanya 10-20 baris dalam 4th
GL. Dibandingkan dengan 3th GL yang membutuhkan prosedur, pada 4th GL
tidak diperlukan lagi dan pengguna bisa menetukan apa saja yang harus yang
dilakukan.
12
4th GL diharapkan dapat memudahkan penggunaannya pada tingkat
komponen yang lebih tinggi seperti tools generasi ke-4. para pengguna tidak
mengharapkan untuk mendefinisikan langkah suatu program untuk melaksanakan
suatu tugas, tetapi lebih mendefinisikan parameter untuk tools yang mana untuk
menciptakan suatu program aplikasi. 4th GL diyakini dapat mengembangkan
produktifitas dalam batasan jenis masalah yang bisa diatasi oleh 4th GL :
• Presentasi bahasa, seperti Query Language dan Report Generator.
• Bahasa khusus, seperti spreadsheets dan database language.
• Aplikasi generator yang dapat mendefinisikan, menyisipkan,
memperbaharui, dan membuka kembali data dari suatu basisdata untuk
membuat suatu aplikasi.
• Bahasa tingkat paling tinggi yang biasa digunakan untuk membuat suatu
kode aplikasi.
SQL dan QBE, seperti yang disebutkan diatas adalah contoh dari 4th GL.
Sekarang kita berbicara beberapa contoh dari tipe lain dari 4th GL :
• A forms generator.
• Report generator.
• Graphics generator.
• Aplikasi generator.
13
2.1.7 Siklus Hidup Aplikasi Database
Siklus hidup aplikasi database merupakan tahapan dalam merancang suatu
sistem database. Siklus hidup aplikasi database digambarkan seperti bagan berikut
ini ( Connolly, 2002, p272 ).
14
Gambar 2.1 Database Life Cycle
Database Planning
System Definition
Conceptual Database design
Requirements Collection And Analysis
Physical databse design
Logical Database design
DBMS selection (optional)
Application Design
Prototyping (optional)
implementation
Data Conversion and Loading
Testing
Operational Maintenance
15
2.1.7.1 Database Planning
Mengatur atau merencanakan aktivitas-aktivitas dengan mengikuti
langkah-langkah dari aplikasi database daan diterapkan se-efektif dan se-
efisien mungkin. Ada tiga masalah pokok yang harus diperhatikan dalam
merumuskan strategi sistem informasi (Connolly, 2002, p273)
• mengidentifikasikan rencana dan tujuan perusahaan dengan
menetukan sistem informasi yang diperlukan.
• Mengevaluasi sistem informasi yang ada untuk mellihat kelebihan
dan kekurangannya.
• Penilaian mengenai peluang IT yang mungkin dapat menghasilkan
keuntungan yang kompetitif.
2.1.7.2 System Definition
Mendeskripsikan ruang lingkup dari aplikasi database yang akan dibuat
termasuk user dan tempat aplikasi database diterapkan (Connolly, 2002,
p274). Sebelum mencoba untuk merancang suatu aplikasi database,
sangatlah penting untuk kita mengidentifikasikan batasan-batasan sistem
yang ada dan bagaimana sistem tersebut berintraksi dengan bagian sistem
informasi yang lain dalam perusahaan tersebut. Penting juga untuk
mengikutsertakan didalam batasan-batasan sistem yang kita buat tidak
hanya untuk aplikasi dan pemakai saat ini saja tetapi bisa digunakan di
masa yang akan datang.
16
2.1.7.3 Requirement Collection and Analysis
Proses mengumpulkan dan menganalisa kebutuhan-kebutuhan user.
Langkah ini melibatkan pengumpulan dan analisa dari informasi tentang
bagian dari perusahaan yang akan dibuat sebuah basis data. Ada banyak
teknik untuk memperoleh informasi, dan disebut dengan fact-finding
techiques. Informasi yang dikumpulkan mencakup :
• Deskripsi tentang data yang digunakan.
• Keterangan secara lengkap bagaimana data tersebut digunakan.
• Kebutuhan tambahan lainnya utnuk aplikasi data yang baru.
Informasi ini kemudian akan dianalisa untuk mengidentifikasikan
kebutuhan yang tercakup dalam aplikasi database yang baru. Kebutuhan
ini diuraikan dalam dokumen secara bersama dikenal sebagai spesifikasi
kebutuhan untuk aplikasi database yang baru. Analisa dan koleksi
kebutuhan adalah suatu langkah persiapan untuk merancang suatu basis
data. Jumlah data yang kumpukan tergantung pada sifat alami dari
masalah dan kebijakan perusahaan. Mengidentifikasi kemampuan yang
diperlukan untuk suatu aplikasi database adalah suatu aktifitas yang
penting, karena sistem dengan kemampuan yang tidak sempurna atau tidak
cukup akan mengganggu user, yang memungkinkan sistem tersebut tidak
digunakan lagi atau ditolak. Bagaimanapun, kemampuan sistem yang
berlebihan dapat juga menjadi masalah, misalnya suatu sistem yang terlalu
17
rumit dapat membuat sukar untuk penerapan, pemeliharaan, penggunaan
atau belajar menggunakan sistem tersebut.
2.1.7.4 Database Design
Proses dalam membuat suatu desain untuk database yang didukung
operasi sistem yang ada di perusahaan tersebut.(Connolly, 2002, p279).
Dalam bagian ini terdapat tiga tahap dalam merancang suatu data base
yaitu Conceptual desin, logical design, Physical design. Tahap- tahap ini
akan dijelaskan di sub bab berikutnya.
2.1.7.5 Prototyping
Membangun suatu model kerja dari aplikasi database. Tujuan utama
mengembangkan suatu prototipe aplikasi database adalah mengizinkan
user untuk menggunakan prototype guna mengidentifikasikan corak
sistem apakah bekerja dengan baik dan jika mungkin meningkatkan corak
baru kepada aplikasi database. Dengan cara ini kita dapat memperjelas
kebutuhan pemakai dan pengembang sistem dalam mengevaluasi
kelayakan design sistem tertentu. Prototipe perlu mempunyai keuntungan
yang utama yang secara relatif cepat dan murah untuk dibangun.
Ada dua strategi yang digunakan saat ini yaitu requirement prototyping
dan evolutionary protoptyping. Requirement prototyping digunakan untuk
menentukan kebutuhan suatu aplikasi database yang diusulkan dan ketika
kebutuhan terhadap suatu aplikasi database tidak lengkap, maka prototype
18
tersebut tidak digunakan lagi. Evolutionary prototyping digunakan untuk
tujuan yang sama, perbedaan yang penting adalah bahwa prototype tidak
dibuang tetapi dengan pengembangan lebih lanjut, prototype tersebut
bekerja sama dengan aplikasi database.
2.1.7.6 Implementation
Impelemntasi merupakan realisasi secara fisik dari database dan desain
aplikasi (Connolly, 2002, p292). Pada tahap penyelesaian desain ( dimana
dapat melibatkan pembuatan prototype atau tidak ), kini kita dapat
menerapkan basis data dan program aplikasi yang telah kita buat.
Implementasi basis data menggunakan DDL yang kita pilih dalam
melakukan pemilihan DBMS atau dengan menggunakan Graphical User
Interface (GUI), yang menyediakan fungsional yang sama dengan
pernyataan DDL yang low level. Pernyataan DDL digunakan untuk
menciptakan struktur basis data dan mengosongkan file yang terdapat
dalam basis data tersebut.
Program aplikasi diterapkan dengan menggunakan bahasa generasi ke-4
ataua ke-3 yang lebih disukai. Bagian dari program aplikasi ini adalah
transaksi basis data, yang diterapkan dengan menggunakan DML.
Transaksi basis data juga dapat dibuat dalam bahasa pemrograman seperti
Visual Basic, Delphi, C, C++, Java, Cobol, Fortran, Ada, atau Pascal. Kita
juga menerapkan komponen lain dari desain aplikasi seperti layar menu,
format masukan data, dan laporan.
19
Pengendalian keamanan dan intergritas untuk aplikasi juga telah
diterapkan. Sebagian dari kendali ini telah diterapkan dengan
menggunakan DDL, tetapi yang lain mungkin perlu untuk digambarkan di
luar dari DDL, sebagai contoh penggunaan yang disediakan DBMS atau
kendali sistem opereasi.
2.1.7.7 Data Conversion and Loading
Pemindahan data yang ada dalam basis data yang baru dan mengubah
aplikasi yang sedang berjalan agar dapat digunakan dalam basis data yang
baru (Connolly, 2002, p293) langkah ini diperlukan hanya ketika suatu
sistem basis data baru sedang menggantikan suatu sistem basis data yang
lama. Sekarang ini, telah menjadi umum suatu DBMS untuk mempunyai
suatu kegunaan yang dapat mengisi file yang ada kedalam basis data yang
baru. Kegunaan yang ada umumnya memerlukan spesifikasi sumber file
dan target basis data dan kemudian secara otomatis mengkonversi data itu
kepada format yang diperlukan basis data yang baru. Kapan saja konversi
dan pembuatan diperlukan proses harus dengan baik direncanakan agar
basis data tersebut dapat sesuai dengan kebutuhan yang ada.
2.1.7.8 Testing
Testing adalah sautu proses melaksanakan program aplikasi dengan tujuan
menemukan kesalahan (Connolly, 2002 p293). Sebelum diterapkan dalam
suatu sistem, basis data harus dilakukan testing terlebih dahulu. Hal ini
dicapai dengan penggunaan secara hati-hati untuk merencanakan suatu
20
test dan data yang realitis sedemikian sehingga keseluruhan proses
pengujian sesuai dengan metode dan dillaksanakan sesuai aturan yang ada.
2.1.7.9 Operastional Maintenance
Suatu proses untuk memonitor dan merawat sistem setelah instalasi.
Dalam langkah- langkah yang sebelumnya, aplikasi basis data telah secra
penuh diterapkan dan diuji. Sistem sekarang pindah kesuatu langkah
pemeliharaan, yang melibatkan aktifitas yang berikut (Connolly, 2002,
p293) :
• Monitoring performance dari sistem. Jika performance jatuh
dibawah suatu tingkatan yang bisa diterima, penyetelan atau
reorganisai basis data mungkin diperlukan.
• Maintaning dan meningkatkan mutu aplikasi basis data ( ketika
diperlukan ). Kebutuhan baru disatukan ke dalam aplikasi data
dengan mengikuti langkah-langkah sebelumnya yang terdapat
dalam database life cycle.
Ketika aplikasi basis data sedang beroperasi, perlu dilakukan monitoring
secara dekat untuk memastikan bahwa performance dalam tingkatan yang
bisa diterima. Suatu DBMS secara normal menyediakan berbagai
kegunaan untuk membantu administrasi basis data yang mencakup
kegunaan untuk mengisi data kedalam suatu basis data dan memonitor
sistem tersebut. Kegunaan yang mengizinkan sistem melakukan
monitoring secara berdampingan atau berhadapan informasi sebagai
21
contoh, pemakaian basis data mengunci efisiensi dan query strategi
pelaksanaan. Database Administrator (DBA) dapat menggunakan
informasi ini untuk menyetel sistem dan untuk memberi performance yang
lebih baik, sebagai contoh, dengan menciptakan index tambahan untuk
mempercepat query, dengan mengubah struktur basis data, atau dengan
melakukan kombinasi terhadap tabel yang ada.
Monitoring process akan terus berlanjut pada sepanjang hidup suatu
aplikasi basis data tersebut dan pada waktu tertentu boleh melakukan
reorganisai basis data untuk mencukupi kebutuhan dari sistem. Perubahan
ini menyediakan informasi pada evolusi sistem dan sumber daya yang ada
pada masa yang akan datang mungkin diperlukan. Hal ini memungkinkan
DBA untuk terlibat dalam perencanaan kapasitas dan untuk memberi tahu
staff senior siaga untuk melakukan penyesuaian rencana. Jika DBMS
kekurangan kegunaan tertentu, DBA dapat mengembangkan kegunaan
yang diperlukan atau membeli tools tambahan jika tersedia.
22
2.1.8 Design Conseptual, Logical dan Physical Database
1. Conceptual database design
Langkah awal dalam conceptual database adalah dengan membuat model
data secara konseptual dari perusahaan yang bersangkutan. Data tersebut
merupakan informasi-informasi mengenai perusahaan. Dalam menentukan model
data secara konseptual data yang digunakan tidak termasuk dalam sasaran DBMS,
program aplikasi, bahasa pemrograman, dan masalah dalam pembuatan basis data.
Dalam conceptual database design data yang ada dikembangkan dengan
representasi secara konseptual yang mencakup mengidentifikasi entity,
relasionship dan atribut yang sangat penting dalam perancangan basis data
tersebut.
2. Logical database design
Dalam logical database design, model data yang telah diperoleh dalam
consceptual database design diubah dalam bentuk logical model dimana data
yang ada dipengaruhi oleh model data yang menjadi tujuan basis data (database).
Hal ini dilakukan untuk menerjemahkann representasi konseptual ke dalam
bentuk struktur logic dalam database. Logical data model merupakan sumber
informasi dalam merancang physical database. Logical database design
memberikan sarana yang membantu para perancang dalam merancang physical
database.
23
3. Physical database design
Physical database design dilakukan untuk memutuskan struktur logik
secara fisik diimplementasikan kedalam tujuan Database Management System
(DBMS), para perancang juga harus membuat keputusan mengenai bagaimana
basis data (database) tersebut dapat diimplementasikan / diterapkan dalam
perusahaan. Oleh karena itu, physical database design harus disesuaikan dengan
DBMS yang spesifik.
Terdapat hubungan antara physical daatabase design untuk meningkatkan
kinerja dari basis data tersebut dapat mempengaruhi logical data model.
2.2 Teori-Teori Lain
24
2.2.1 Pengertian Security dan Integrity
Kata security dan integrity sering didengar dan dimengerti secara serupa
didalam konteks database, tetapi sebenarnya keduanya mempunyai konsep yang
berbeda. Security lebih mengacu pada proteksi data terhadap otorisasi yang tidak
dinginkan. Sedangkan integrity mengacu pada keakuratan dan validasi data (
Date, 1990, p429 ).
Jadi dengan kata lain yang dimaksud dengan security dalam database
yaitu memastikan bahwa para pemakai diijinkan untuk melakukan hal-hal yang
mereka sedang dilakukan. Sedangkan integrity itu sendiri adalah memastikan
bahwa hal-hal yang sedang diproses dilakukan dengan benar.
Tetapi ada beberapa persamaan akan keduanya, yaitu:
Dalam kasus ini sistem perlu memberi batasan tertentu dimana pemakai tidak
boleh melanggarnya, di mana batasan untuk keduanya haruslah spesifik (
khususnya untuk DBA) dalam bahasa pemrograman yang digunakan, dan harus
dipelihara dalam suatu sistem yang dapat berupa catalog atau kamus. Untuk
keduanya DBMS harus memonitor interaksi pemakai dalam beberapa cara untuk
memastikan bahwa batasan benar berfungsi.
2.2.2 Keamanan: pertimbangan umum
Ada banyak aspek untuk masalah keamanan ( Date, 1990, p430 ),
diantaranya:
25
• Legal, sosial dan aspek etis ( sebagai contoh, ada user yang melakukan
transaksi, katakan untuk suatu kredit pelanggan, apakah user mempunyai
akses legal untuk informasi yang diminta ? )
• Kendali fisik ( sebagai contoh, perlukah ruang terminal atau komputer
dikunci atau harus menggunakan cara lain ? )
• Pertanyaan kebijakan( sebagai contoh, bagaimana cara perusahaan memiliki
suatu sistem yang dapat memutuskan siapa yang diijinkan akses ke suatu
sistem dan untuk apa ? )
• Masalah operasi ( sebagai contoh, jika password digunakan, bagaimana
merahasiakannya? Seberapa sering mereka merubah password tersebut?)
• Kontrol hardware ( sebagai contoh, apakah CPU menyediakan feature
keamanan, seperti kunci-kunci untuk perlindungan dalam penyimpanan )
• Keamanan sistem operasi ( sebagai contoh, apakah sistem operasi dapat
mendukung suatu sistem dalam melakukan proses penghapusan dan
penyimpanan data ? )
• Isu yang terfokus pada sistem database sendiri secara spesifik ( sebagai
contoh, apakah sistem database mempunyai suatu konsep kepemilikan data ? )
2.2.3 Teori Persediaan
2.2.3.1 Penilaian dan pelaporan
Pesediaan barang dagang (merchandise inventory) adalah barang-barang
yang dimiliki peursahaan untuk dijual kembali. Untuk perusahaan pabrik,
termasuk dalam persediaan adalah barang-barang yang akan digunakan untuk
26
proses produksi selanjutnya. Persedian dalam perusahaan pabrik terdiri dari
persediaan bahan baku, persediaan dalam proses dan persediaan barang jadi.
Persediaan pada umumnya, meliputi jenis barang yang cukup banyak dan
merupakan bagian yang cukup berarti dari seluruh aktiva perusahaan.Di
samping itu, transaksi yang berhubungan dengan persediaan merupakan aktifitas
yang paling sering terjadi (Soemarso S.R, 1992, p411).
Persediaan barang dagang pada umumnya dinilai pada harga
perolehannya. Dalam hal-hal tertentu persediaan dapat dinilai pada harga
terendah antara harga perolehan dan harga pasar atau nilai yang diharapkan
dapat direalisasikan. Cara penilaian dan metode penerapan harga pokok harus
diungkapkan dalam laporan keuangan .
2.2.3.2 Pesediaan dalam Laporan Keuangan
Dalam laporan keuangan, persediaan barang dagang disajikan baik
dineraca maupun perhitungan rugi laba. Persediaan barang dagang yang
tercantum dineraca mencerminkan nilai barang dagang yang ada pada tanggal
neraca, yang biasanya juga merupakan akhir dari suatu periode akuntansi.
Diperhitungkan rugi laba, persediaan barang dagang muncul dalam harga pokok
penjualan (Soemarso S.R, 1992, p412)..
27
2.2.3.3 Metode FIFO ( First In First Out )
Metode penetapan harga pokok persediaan dimana bahwa barang-barang
yang terdahulu di beli akan merupakan barang yang dijual pertama kali. Dalam
metode ini persediaan akhir dinilai dengan harga pokok pembelian yang paling
akhir (Soemarso S.R, 1992, p416).
2.2.3.4 Metode Identifikasi Khusus ( specific identification )
Dalam metode ini, harga pokok yang dibebankan barang-barang yang
dijual dan yang masih ada dalam persedian didasarkan atas harga pokok yang
dikeluarkan khusus untuk barang – barang yang bersangkutan. Metode ini,
dalam praktek, hanya cocok untuk barang –barang yang jumlahnya tidak banyak
dan nilai per satuaannya tinggi, seperti misalnya mobil bekas dan lukisan.
2.2.3.5 Metode eceran (retail metohd)
Penetapan harga pokok persediaan secara taksiran yang didasarkan atas
hubungan, yang terdapat dalam tahun berjalan, antara harga pokok dengan
harga jual.
2.2.3.6 Metode laba bruto atau laba kotor
Metode penetapan harga pokok persediaan secara taksiran yang
didasarkan atas hubungan, yang terdapat pada periode yang lalu, antara
28
harga pokok dengan harga jual. Metode ini pada dasarnya menggunakan
konsep yang sama dengan metode eceran, yaitu konsep hubungan antara
harga pokok dan penjualan. Perbedaannya dengan metode eceran terletak
dalam cara penentuan prosentase. Kalau dalam metode eceran prosentase
harga pokok terhadap harga jual didasarkan atas harga pokok dan harga
jual aktual selama suatu periode, dalam metode laba bruto prosentase laba
bruto terhadap penjualan didasarkan laporan keuangan tahun lalu
perbedaan lainnya adalah kalau metode eceran menggunakan prosentase
harga pokok terhadap harga jual, metode laba bruto menggunakan
prosentase laba bruto tehadap penjualan.
2.2.3.7 Metode LIFO (Last In Fisrt Out)
Metode penetapan harga pokok persediaan dimana dianggap bahwa
baranag-barang yang paling akhir dibeli akan merupakan barang yang
dijual pertama kali. Dalam metode ini, persediaan akhir akan dinilai
dengan harga pokok pembelian yang terdahulu.
2.2.3.8 Metode rata-rata
Metode penetapan harga pokok persediaan dimana dianggap bahwa harga
pokok rata-rata dari barang yang tersedia dijual akan digunakan untuk menilai
harga pokok barang yang dijual dan yang terdapat dalam persediaan.