BAB 2 Landasan Teori 2.1
Pendekatan BasisData Penggunaan basisdata yang tradisioanal adalah File-Based System. Setiap
program yang menggunakan File-Based System akan mendefinisikan dan mengontrol masing-masing data program itu sendiri. Tetapi aplikasi File-Based System mempunyai banyak kelemahan,contohnya :
Data terpisah-pisah
Data yang terisolasi pada file berbeda mengakibatkan semakin sulitnya pengaksesan terhadap data tersebut.
Duplikasi data
Karena setiap programmer membuat file dan aplikasi dalam jangka waktu yang lama, variasi file memiliki format yang berbeda dan kemungkinan program tersebut ditulis oleh bahasa program yang berbeda-beda. Oleh Karena itu, kemungkianan informasi yang sama dapat berbeda pada beberapa file
Ketergantungan Data
Struktur fisik dari file data dan record didefinisikan pada kode aplikasi. Hal ini mengakibatkan pengubahan dari struktur yang telah ada menjadi sulit dilakukan.
Format data yang tidak kompatibel Karena struktur file tersimpan pada program aplikasi, struktur tersebut
menjadi tergantung pada bahasa pemrograman yang digunakan.
Fixed query
File-Based System menawarkan system yang lebih baik, tetapi seiring dengan perkembangan akan muncul permintaan-permintaan query baru. Hal ini 8
9 membutuhkan pembuatan program tambahan untuk menjalankan query tersebut. Hal ini membutuhka waktu yang lama dan tamahan biaya sehingga dapat menurunkan efektifitas dari system. Dengan adanya kekurangan dari File-Based System, maka dibuatlah sisem basisdata yang merupakan pendekatan baru yang dibutuhkan untuk mengatasi kelemahan tersebut. Salah satu dari sistem basisdata adalah Database dan Database Management System (DBMS).
2.1.1
Pengertian BasisData Menurut Gerard V. Post (2005,p2) basisdata adalah koleksi penyimpanan data
berdasarkan standar format yang dirancang agar bisa digunakan bersama-sama oleh user yang berbeda-beda. Menurut Ramakrishman (3005, p4) basisdata adalah koleksi data, yang bertipikal penjelasan aktivitas dari satu atau lebih relasi organisasi. Menurut Atzeni, dkk (2003, p2) basisdata adalah koleksi data, yang digunakan untk merepresentasikan informasi yang menarik ke dalam sistem informasi. Maka dari itu, kami menyimpulkan bahwa basisdata adalah koleksi data yang bertipikal aktivitas dari satu atau lebih relasi organisasi yang dirancang agar bisa digunakan bersama-sama dan disimpan untuk kepentingan organisasi atau perusahaan.
2.1.2
Database Management System (DBMS) DBMS (Basisdata Management System) menurut Hofer (2005, p7) adalah sistem
yang digunakan untuk membuat, merawat dan menyediakan control akses untuk
10 pengguna basisdata. DBMS menyediakan metode sistematik untuk pembuatan, updating, penyimpanan dan penerimaan data pada basisdata. DBMS juga menyediakan fasilitas untuk mengontrol akses data, menguatkan integritas data, mengatur control konkurensi, dan menyimpan basisdata. DBMS menurut Gererd V. Post ( 2005, p2) adalah yang menjelaskan basisdata, penyimpanan data, mendukung bahasa query, memproduksi laporan, dan membuat layer data entry. DBMS menurut Atzeni dkk (2003, p3) adalah sistem piranti lunak yang memungkinkan untuk mengatur koleksi data yang banyak, berbagi dan persisten serta untuk memastikan reliabilitas dan privacy mereka. Seperti produk yang lainnya, DBMS harus efisien dan efektif. Basisdata adalah koleksi data yang diatur oleh DBMS. DBMS menurut Connolly (2005, p17) adalah suatu sistem piranti lunak yang memungkinkan user untk mendefinisikan, membuat, merawat, dan mengontrol akses ke dalam basisdata.
2.1.3
Data Definition Language (DDL) Definisi dari Data Definition Language menurut Connolly (2005, p40) adalah
suatu bahasa yang memperbolehkan Database Administrator (DBA) atau user untuk mendeskripsikan nama dari suatu entity, atribut, dan relationship data yang diminta oleh aplikasi, bersamaan dengan integritas data dan batasan keamanan datanya.
11 2.1.4
Database Manipulation Language (DML) DML menurut Gerard V. Post (2005, p146) adalah sebuah rangkaian dari
perintah-perintah yang digunakan untuk mengakses data. Contohnya Command Insert, Delete, dan Update. DML menurut Connolly (2005, p40) adalah suatu bahasa yang memberikan fasilitas pengoperasian data yang ada di dalam basis data. Pengoperasian data yang akan dimanipulasi biasanya meliputi: 1.
Penambahan data baru ke dalam basisdata.
2.
Modifikasi data yang disimpan ke dalam basisdata.
3.
Pengambilan data yang terdapat di dalam basisdata.
Sedangkan definisi Procedural DML menurut Connolly (2005, p41) adalah suatu bahasa yang memperbolehkan user untuk mendeskripsikan ke sistem data apa yang dibutuhkan dan bagaimana mendapatkan data tersebut secara persis.
2.1.5
4GL Fourth-Generalazatin Languages atau 4th GLs menurut Connolly (2005,p42)
adalah generasi bahasa tingkat empat. Tidak ada konsensus tentang apa itu 4 th GLs, ditunjukkan untuk bahasa pemrograman yang sederhana suatu operasi yang membutuhkan banyak baris dalam bahasa generasi tingkat tiga (3th GLs), seperti COBOL, biasanya membutuhkan hanya 10-20 baris 4th GLs. Dibandingkan dengan 3 th GLs, yang membutuhkan produser,pada 4th GLs tidak diperlukan lagi dan pengguna bisa menentukan apa saja yang harus dilakukan. 4 th GLs diharapkan dapat memudahkan penggunanya pada tingkat komponen yang lebih tinggi seperti tools generasi ke-4. Para pengguna tidak mengharapkan untuk
12 mendefinisikan langkah suatu program untuk melaksanakan suatu tugas, tetapi lebih mendefinisikan parameter untuk tools yang mana untuk menciptakan suatu program aplikasi. 4 th GLs diyakini dapat mengembangkan produktivitas dalam batasan jenis masalah yang bisa diatasi oelh 4th GLs: -
Presentasi bahasa, seperti query language and report generator
-
Bahasa khusus, seperti spreadsheets dan basisdata language
-
Aplikasi generator yang dapat mendefinikan, menyisipkan, memperbaharui, dan membuka kembali data dari suatu basis data untuk membuat aplikasi.
2.1.6
Database Life Cycle Sistem informasi berbasis computer terdiri dari sebuah database, piranti lunak
database, piranti lunak aplikasi, perangkat keras komputer dan pemakanian perseorangan dan perkembangan sistem. Komponen terpenting dari sistem informasi adalah database. Pemakian dan perkembangan dari database harus memenuhi kebutuhan tersebar dari perusahaan. Tingkat dari information system lifecycle atau software development lifecycle (SDLC) terdiri dari perencanaan, analisis kebutuhan, perancangan pembuatan prototype, implementasi, konversi dan operasi pemeliharaan. Tingkatan dari database application lifecycle memiliki bentuk yang tidak kaku, tetapi mengikuti bentuk dari bentuk semula yaitu feedback loops. Untuk aplikasi database kecil, dengan jumlah pemakai yang kecil, siklus hidup yang diperlukan tidak terlalu kompleks. Meskipun begitu, ketika merancang database aplikasi menengah ke atas dengan jumlah pemakai dari 10 hingga 1000, menggunakan ratusan query dan program aplikasi, sisklus hidup dapat menjadi komplek.
13
Gambar 2.1 Tingkatan dari Database System Development Lifecycle ( Sumber : Connolly dan Begg , 2005 , p284 ) 2.1.6.1 Database Planning Adalah aktifitas manajemen yang memungkinkan setiap tahapan dalam Database System Development Lifecycle untuk direalisasikan seefisien dan seefektif mungkin. Database Planning seharusnya diintegrasikan dengan
14 keseluruhan strategi Information System dari organisasi. Ada 3 persoalan utama dalam menyusun strategi IS, antara lain : 1. Identifikasi dari rencana dan tujuan perusahaan dengan determinasi secara subsequent dari kebutuhan sistem informasi. 2. Mengevaluasi sistem informasi yang ada untuk mendefinisikan kekuatan dan kelemahan. 3.
Penafsiran dari IT opportunity untuk mendapatkan keuntungan bersaing.
2.1.6.2 Sistem Definition Sistem definisi mendeskripsikan cakupan dan batasan dari aplikasi basisdata dan user view utama. User view mendeskripsikan apa yang dibutuhkan dari sebuah basisdata dari sudut pandang peran pekerja (seperti manager atau supervisor) atau area aplikasi perusahaan (seperti marketing, personel, atau kontrol stok).
2.1.6.3 Requirements Collection and Analysis Suatu proses yang mengumpulkan dan menganalisis informasi mengenai bagian dari organisasi yang didukung oleh aplikasi basisdata dan penggunaan informasi ini untuk mengidentifikasi kebutuhan pengguna dari sistem yang baru. Untuk mengumpulkan dan menganalisis informasi digunakan teknik yang dinamakan teknik fact-finding. Menurut Connolly dan Begg ( 2005, p317), terdapat lima teknik fact finding yang umum digunakan:
15 •
Mengevaluasi dokumentasi.
•
Interview.
•
Observasi.
•
Research.
•
Questioner.
2.1.6.4 Database Design Menurut Connolly dan Begg ( 2005 , p291 ), Database design adalah suatu proses yang membuat suatu rancangan untuk basisdata yang akan mendukung kegiatan operasional dan tujuan dari perusahaan. Pada bagian ini dibagi menjadi tiga tahap, yaitu conceptual, logical, dan physical 1. Conceptual database design Pada tahap konseptual ini bertujuan untuk membuat representasi konseptual dari basis data, termasuk identifikasi entitas, relationship, dan atribut. Pada tahap ini dibagi menjadi beberapa langkah, yaitu: Langkah 1. Membangun conceptual data model Langkah 1.1
Identifikasikan Tipe Entitas
Langkah 1.2
Identifikasikan Tipe Relationship
Langkah 1.3
Identifikasikan dan Asosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship
Langkah 1.4
Menentukan Domain Atribut
Langkah 1.5
Penentuan Atribut Candidate key, Primary Key, dan Alternate Key
16 Langkah 1.6
Mempertimbangkan
penggunaan
enhanced
modeling
concept (optional) Langkah 1.7
Memeriksa model dari redundancy
Langkah 1.8
Validasi Model Konseptual dengan user transaction
Langkah 1.9
Meninjau local conceptual data model dengan pengguna
2. Logical database design Pada tahap ini memetakan model konseptual ke model logikal yang dipengaruhi oleh model data yang menjadi tujuan dari basisdata. Dalam perancangan model logikal, model data yang telah diperoleh dalam basisdata konseptual diubah dalam bentuk dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan basisdata (contoh : relational model). Hal ini dilakukan untuk menerjemahkan representasi konseptual kedalam bentuk struktur logik dalam basisdata. Model data logikal merupakan sumber informasi dalam merancang basisdata fisikal. Perancangan basisdata logikal memberikan sarana yang membantu para perancang dalam merancang basisdata fisikal. Pada tahap ini dibagi menjadi beberapa langkah, yaitu : Langkah 2. Membangun dan memvalidasi logical data model Langkah 2.1
Menentukan Relasi – Relasi untuk Model Data Logikal
Langkah 2.2
Validasi Model dengan Normalisasi
Langkah 2.3
Memvalidasi Relasi dengan User Transaction
Langkah 2.4
Mendefinisikan Kendala Integrity
Langkah 2.5
Me-review logical data model dengan User
17 Langkah 2.6
Menggabungkan Logical Data Model ke dalam Global Model (optional)
Langkah 2.7
Memeriksa untuk perkembangan lebih lanjut
3. Physical database design Tahap physical datanbase design memungkinkan perancang basisdata untuk
membuat
keputusan
mengenai
bagaimana
basisdata
akan
diimplementasikan. Oleh karena itu, physical databse design harus disesuaikan dengan DBMS yang spesifik. Pada tahap ini dibagi menjadi beberapa langkah, yaitu : Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Langkah 3.1
Merancang relasi – relasi dasar
Langkah 3.2
Merancang representasi untuk data Turunan
Langkah 3.3
Merancang general constraint
Langkah 4. Merancang file organization dan indexes Langkah 4.1
Menganalisa transaksi
Langkah 4.2
Memilih organisasi file
Langkah 4.3
Memillih index – index
Langkah 4.4
Memperkirakan kebutuhan disk space
Langkah 5. Merancang user view Langkah 6. Merancang mekanisme keamanan Langkah 7. Mempertimbangkan pengenalan redudancy control Langkah 8. Mengawasi dan mengendalikan sistem operasional
18 2.1.6.5 DBMS Selection Pemilihan DBMS dilakukan untuk memilih DBMS yang sesuai dengan aplikasi basisdata. Menurut Connolly dan Begg ( 2005, p295 ), berikut ini adalah langkah –langkah dalam memilih DBMS : 1.
Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan
2.
Membuat perbandingan mengenai 2 atau 3 produk DBMS
3.
Mengevaluasi produk-produk DBMS tersebut
4.
Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi produk DBMS tersebut.
Secara khusus DBMS menyediakan fasilitas-fasilitas sebagai berikut : 1.
Mengijinkan pengguna untuk menentukan basisdata, biasanya melalui Data Definition Language (DDL). DDL mengijinkan pengguna untuk menspesifikasikan tipe data, struktur dan batasan-batasan data yang bisa disimpan di basisdata.
2.
Mengijikan pengguna untuk insert, update, delete atau retrive data dari basisdata, biasanya melalui Data Manipulation Language(DML).
3.
DBMS menyediakan akses kontrol ke basisdata. Sebagai contohnya DBMS menyediakan : a. Security system, dimana mencegah autorisasi pengguna untuk mengakses basisdata. b. Integrity system, dimana menangani konsistensi penyimpanan data. c. Concurrency control system, dimana mengijinkan basisdata untuk diakses secara share.
19 d. Recovery control system, dimana basisdata bisa di-restore pada saat terjadi kesalahan pada hardware maupun software. e. User-accesable catalog, dimana berisi deskripsi data dalam basisdata.
2.1.6.6 Application Design Menurut Connolly dan Begg ( 2005 , p299 ), Rancangan aplikasi adalah rancangan dari user interface dan program aplikasi yang digunakan dan memproses basisdata. Dalam kebanyakan kasus tidak mungkin dapat menyelesaikan aplication design sebelum menyelesaikan database design itu sendiri. Dengan kata lain database yang ada mendukung aplikasi sehingga ada banyak aliran infomasi anatar application design dan database design.
2.1.6.7 Prototyping (Optional) Pada kondisi tertentu kita dapat memilih apakah akan membuat prototype atau langsung mengimplementasikan basisdata. Suatu prototype adalah suatu model aplikasi basisdata yang mempunyai semua corak yang diperlukan dan menyediakan semua kemampuan sistem. Tujuan utama prototype itu untuk menguji apakah fitur-fitur yang ada pada sistem telah bekerja sesuai dengan karakteristik pengguna. Dengan cara ini, kita dapat memperjelas kebutuhan pengguna dan pengembangan sistem dan mengevaluasi kelayakan desain sistem tersebut. Menurut Connolly dan Begg ( 2005, p303 ), ada dua cara strategi membuat prototype yaitu requirements prototyping dan evolutioner prototyping. Untuk requirements prototyping digunakan prototype untuk menentukan
20 kebutuhan suatu aplikasi basisdata yang diusulkan dan ketika kebutuhan dirasakan sudah lengkap maka prototype tersebut tidak lagi digunakan. Protype evolutioner digunakan untuk tujuan yang sama, perbedaannya adalah bahwa prototype tidaklah dibuang tapi dikembangkan lebih lanjut sehingga menjadi aplikasi basisdata tersebut.
2.1.6.8 Implementasi Menurut Connolly dan Begg ( 2005, p304 ), implementasi merupakan perwujudan fisik dari basisdata dan desain aplikasi. Setelah menyelesaikan tahap desain (dengan atau tanpa prototype), selanjutnya pada tahap implementasi basisdata dan program aplikasi. Implementasi basisdata dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang telah dipilih atau dengan menggunakan Graphical User Interface (GUI), masing - masing meyediakan fungsi ketika menyembunyikan pernyataan (statement) DDL yang low - level. Pernyataan DDL digunakan untuk menciptakan struktur basisdata dan mengosongkan file yang terdapat dalam basisdata tersebut. User view juga diterapkan dalam langkah implementasi. Program aplikasi diterapkan dengan menggunakan bahasa generasi keempat atau ketiga (4GL atau 3GL). Bagian dari program aplikasi ini adalah transaksi basisdata yang diterapkan menggunakan Data Manipulation Language (DML). Transaksi basisdata juga dapat dibuat dalam bahasa pemrograman seperti Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada, atau Pascal. Juga dapat diterapkan komponen lain dari desain aplikasi seperti layar menu, format masukan data, dan laporan.
21 Pengendalian
keamanan
dan
integritas
untuk
aplikasi
juga
diimplementasikan. Sebagian dari kendali ini telah diterapkan dengan menggunakan DDL, tetapi yang lain mungkin perlu digambarkan diluar DDL. Sebagai contoh, kegunaan yang disediakan DBMS atau kendali sistem operasi.
2.1.6.9 Data Convertion dan Loading Menurut Connolly dan Begg ( 2005, p305 ), pemindahan data yang ada ke basisdata yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basisdata yang baru.
2.1.6.10 Testing Menurut Connolly dan Begg ( 2005, p305 ), Testing adalah suatu proses yang melaksanakan proses aplikasi dengan tujuan menemukan kesalahan. Dalam melakukan testing, para pengguna baru harus dilibatkan untuk menguji proses aplikasi dan basisdata tersebut. Situasi yang ideal untuk pengujian sistem adalah mempunyai suatu tes basisdata pada suatu sistem perangakat keras, tetapi ini sering tidak tersedia. Jika data real yang diharapkan untuk digunakan, maka adalah penting untuk mempunyai backup. Setelah pengujian diselesaikan, maka sistem aplikasi dan basisdata ini telah siap digunakan.
2.1.6.11 Operational Maintenance Menurut Connolly dan Begg ( 2005, p306 ), setelah melalui tahapan-tahapan sebelumnya, maka sistem sekarang telah pada tahap pemeiharaan yang melibatkan aktivitas berikut :
22 1. Monitoring performance dari sistem. Jika performansi berada disuatu tingkatan yang bisa diterima, penyetelan atau menyusun kembali basisdata mungkin diperlukan. 2. Memelihara dan meningkatkan mutu aplikasi basisdata. Kebutuhan baru disatukan kedalam aplikasi basisdata dengan mengikuti langkah – langkah sebelumnya yang terdapat dalam database lifecycle.
Ketika aplikasi bisnis data sedang beroperasi, perlu dilakukan monitoring secara dekat untuk memastikan bahwa performansi dalam tingkatan yang dapat diterima. Monitoring proses akan terus berlanjut sepanjang seluruh hidup suatu aplikasi basisdata tersebut dan pada waktu tertentu boleh melakukan menyusun kembali basisdata untuk mencukupi kebutuhan dari sistem. Perubahan ini meyediakan informasi pada evolusi sistem dan sumber daya pada masa yang akan datang mungkin diperlukan. Hal ini memungkinkan DBA untuk terlibat dalam perencanaan kapasitas dan untuk memberitahu staf senior siaga untuk melakukan penyesuaian rencana jika DBMS kekurangan kegunaan tertentu, DBA dapat mengembangkan kegunaan yang diperlukan atau memberi tools tambahan jika tersedia.
2.1.7
Tahap-Tahap Perancangan BasisData Dalam merancang suatu basisdata melalui beberapa tahapan, sebagai berikut : •
Perancanagan Basisdata Konseptual
•
Perancanagan Basisdata Logikal
23 •
Perancanagan Basisdata Fisikal
2.1.7.1 Perancangan Basisdata Konseptual Menurut Connolly dan Begg ( 2005 , p439 ), perancangan konseptual basisdata adalah proses pembangunan model data yang digunakan di perusahaan, yang tidak bergantung pada semua pertimbangan fisikal. Tujuannya untuk membangun representasi konseptual basisdata, yang meliputi identifikasi dari entitas - entitas, relationship - relationship, dan atribut - atribut yang penting. Menurut Connolly dan Begg ( 2005 , p443 ), langkah - langkah perancangan konseptual basisdata yaitu : Langkah 1. Membangun Conceptual Data Model Menurut Connolly dan Begg ( 2005 , p442 ), tujuannya adalah untuk membangun local conceptual data model dari perusahaan untuk tiap view yang spesifik. Tiap local conceptual data model terdiri dari entity type, relation type, atribut - atribut, domain – domain atribut, primary key, alternate key, dan integrity constraint. Langkah - langkah yang harus dilakukan pada langkah 1 : Langkah 1.1 Identifikasikan Tipe Entitas Menurut Connolly dan Begg ( 2005, p443 ), tujuannya adalah mengidentifikasikan tipe – tipe entitas utama yang dibutuhkan oleh view. Langkah 1.2 Identifikasikan Tipe Relationship Menurut Connolly dan Begg ( 2005 , p445 ), tujuannya adalah mengidentifikasikan relationship – relationship penting yang ada diantara tipe – tipe entitas yang telah diidentifikasi.
24 Langkah 1.3 Identifikasikan dan Asiosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship Menurut Connolly dan Begg ( 2005 , p447 ), tujuannya adalah untuk menghubungkan atribut – atribut dengan entitas atau relationship type yang sesuai. Langkah 1.4 Menentukan Domain Atribut Menurut Connolly dan Begg ( 2005 , p450 ), tujuannya adalah untuk menentukan domain – domain untuk atribut – atribut dalam local conceptual data model. Domain atribut adalah kumpulan nilai yang diperbolehkan untuk satu atau lebih atribut. Domain merupakan fitur yang sangat kuat dalam model relational. Setiap atribut di dalam relasi ditetapkan dalam domain. Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin ditetapkan dalam domain yang sama. Langkah 1.5 Penentuan Atribut Candidate Key, Primary Key, dan Alternate Key Menurut Connolly dan Begg ( 2005 , p451 ), tujuannya adalah untuk mengidentifikasikan candidate – candidate key untuk tiap tipe entitas dan, jika terdapat lebih dari satu candidate key, maka pilih salah satu untuk dijadikan primary key. Menurut Connolly dan Begg ( 2005 , p451 ), ketika memilih primary key diantara candidate key, kita dapat menggunakan panduan berikut untuk membantu pemilihan primary key, yaitu : -
Candidate key dengan kumpulan atribut yang minimal
-
Candidate key yang nilainya jarang berubah
25 -
Candidate key dengan karakter – karakter yang paling sedikit (untuk yang memiliki textual attributes)
-
Candidate key dengan nilai maksimum paling rendah (untuk yang memiliki numerical attributes)
-
Candidate key yang paling mudah digunakan dari sudut pandang user
Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept (optional) Menurut Connolly dan Begg ( 2005 , p453 ), tujuannya adalah untuk mempertimbangkan
penggunaan
enhanced
modeling
concepts,
seperti
specialization / generalization, aggregation, dan composition. Langkah 1.7 Memeriksa model dari redundancy Menurut Connolly dan Begg ( 2005 , p453 ), tujuannya adalah untuk memeriksa apakah terdapat redundancy dalam model. Dua kegiatan dalam langkah ini adalah : memeriksa kembali one-to-one relationship dan menghilangkan redundant relationships. Langkah 1.8 Validasi Model Konseptual dengan User Transaction Menurut Connolly dan Begg ( 2005 , p456 ), tujuannya adalah untuk menjamin bahwa model konseptual mendukung transaksi – transaksi yang dibutuhkan oleh view. Langkah 1.9 Meninjau local conceptual data model dengan pengguna Menurut Connolly dan Begg ( 2005 , p458 ), tujuannya adalah untuk meninjau local conceptual data model dengan user untuk menjamin bahwa model tersebut adalah representasi yang sebenarnya dari data yang dibutuhkan oleh perusahaan.
26 Supervisor 1 .. 1 Supervises
{Optional} Registers
Staff
0 .. 10
staffNo {PK} 1 .. 1 name fName lName position sex DOB Manages 0 .. 1 0 .. *
0 .. 100 PropertyForRent
1 .. *
Owns
propertyNo {PK} 0 .. * address street city postcode type rooms rent
1 .. 1
Client
Views
0 .. * clientNo {PK} name fName lName telNo viewDate comment
1 .. 1 Holds
1 .. 1 States
1 .. 1
Owner
0 .. *
ownerNo {PK} address telNo
AssociatedWith
{Mandatory, Or} PrivateOwner
BusinessOwner
name fName lName
bName bType contactName
Lease
0 .. *
leaseNo {PK} paymentMethod depositPaid rentStart rentFinish /deposit /duration
1 .. 1 Preference prefType maxRent
Gambar 2.2 ERD Conseptual ( Sumber : Connolly dan Begg , 2005 , p464 )
2.1.7.2 Perancangan Basisdata Logikal Menurut Connolly dan Begg ( 2005 , p439 ), perancangan logikal basisdata adalah suatu proses pembangunan model data yang digunakan dalam perusahaan berdasar atas model data yang spesifik, tetapi tidak bergantung pada
27 particular DBMS dan pertimbangan fisikal lainnya. Tujuannya untuk menerjemahkan representasi konseptual ke struktur logikal dari basisdata yang meliputi perancangan relasi – relasi. Menurut Connolly dan Begg ( 2005 , p462 ), langkah – langkah perancangan basisdata logikal yaitu : Langkah 2. Membangun dan memvalidasi logical data model Menurut Connolly dan Begg ( 2005 , p462 ), tujuannya adalah menerjemahkan logical data model dan kemudian untuk memvalidasi model tersebut untuk memeriksa model tersebut benar secara struktural dan memiliki kemampuan untuk mendukung transaksi – transaksi yang dibutuhkan. Tujuan ini akan tercapai dengan mengikuti langkah – langkah berikut : Langkah 2.1 Menentukan Relasi – Relasi untuk Model Data Logikal Menurut Connolly dan Begg ( 2005 , p463 ), tujuannya adalah menciptakan relasi – relasi untuk model data logikal untuk merepresentasikan entitas – entitas, relationship – relationship, dan atribut – atribut yang telah diidentifikasikan. Relationship yang dapat muncul pada model data konseptual : ● Strong Entity Type dan Weak Entity Type Menurut Connolly dan Begg ( 2005 , p354 ), strong entity type adalah tipe entitas yang keberadaannya tidak bergantung (independent) pada beberapa tipe entitas lainnya. Karakteristik dari strong entity type adalah
tiap
entity occurrence
dapat diidentifikasi
secara
unik
menggunakan atribut primary key dari tipe entitas. Strong entity type sering juga disebut parent atau owner atau dominant entities.
28 Menurut Connolly dan Begg ( 2005 , p355 ), weak entity type adalah tipe entitas yang keberadaannya bergantung (dependent) pada beberapa tipe entitas lainnya. Weak entity type juga disebut child, dependent, atau subordinate entities.
● One-to-many (1:*) binary relationship types Menurut Connolly dan Begg ( 2005 , p465 ), untuk tiap 1:* binary relationship, entitas pada ‘one side’ dari relationship dianggap sebagai entitas parent dan entitas pada ‘many side’ dianggap sebagai entitas child. Untuk merepresentasikan relationship ini, pasangkan salinan primary key dari entitas parent ke dalam relation yang merepresentasikan entitas child, untuk berlaku sebagai foreign key.
● One-to-one (1:1) binary relationsip types Menurut Connolly dan Begg ( 2005 , p465 ), penciptaan relasi relasi untuk merepresentasikan 1:1 relationship sedikit lebih kompleks karena
cardinality
tidak
dapat
digunakan
untuk
membantu
mengidentifikasikan entitas - entitas parent dan child dalam relationship. Sebagai gantinya participation constraint digunakan untuk membantu memutuskan apakah baik untuk merepresentasikan relationship dengan menggabungkan entitas - entitas yang terlibat kedalam satu relasi atau dengan menciptakan dua relasi dengan menyalin salinan dari primary key dari satu relasi ke relasi lainnya. Kita mempertimbangkan bagaimana
29 menciptakan relasi – relasi untuk merepresentasikan participation constraint berikut : -
Mandatory participation pada 2 sisi dari 1:1 relationship
-
Mandatory participation pada 1 sisi dari 1:1 relationship
-
Optional participation pada 2 sisi dari 1:1 relationship
● Mandatory participation pada 2 sisi dari 1:1 relationship Menurut Connolly dan Begg ( 2005 , p466 ), pada kasus ini, kita harus menggabungkan entitas – entitas yang terlibat kedalam satu relasi dan memilih salah satu dari primary key dari entitas – entitas aslinya untuk menjadi primary key dari relasi yang baru, sedangkan yang lainnya dijadikan alternate key.
● Mandatory participation pada 1 sisi dari 1:1 relationship Menurut Connolly dan Begg ( 2005 , p466 ), pada kasus ini, kita dapat mengidentifikasikan entitas - entitas parent dan child untuk 1:1 relationship menggunakan participation constraint. Entitas yang mempunyai optional participation dalam relationship dianggap sebagai entitas parent, dan entitas yang mempunyai mandatory participation dalam relationship dianggap sebagai entitas child. Seperti yang diuraikan diatas, salinan primary key dari entitas parent ditempatkan dalam relasi yang merepresentasikan entitas child. Jika relationship mempunyai satu atau lebih atribut, atribut ini harus menyertakan penyalinan primary key ke relasi child.
30 ● Optional participation pada 2 sisi dari 1:1 relationship Menurut Connolly dan Begg ( 2005 , p467 ), kita dapat memilih primary key mana yang dipilih tergantung dari kasus yang ada. ● One-to-one (1:1) recursive relationship Menurut Connolly dan Begg ( 2005 , p467 ), untuk 1:1 recursive relationship, kita mengikuti aturan untuk participation seperti yang diuraikan untuk 1:1 relationship. Untuk 1:1 recursive relationship dengan mandatory
participation
pada 2
sisi,
representasikan
recursive
relationship sebagai relasi tunggal dengan 2 salinan primary key. Sedangkan salah satu salinan dari primary key merepresentasikan foreign key dan harus diubah namanya untuk menandakan relationship yang direpresentasikan. Untuk 1:1 recursive relationship dengan mandatory participation pada satu sisi, kita mempunyai pilihan untuk menciptakan relasi tunggal dengan 2 salinan primary key atau untuk menciptakan relasi baru untuk merepresentasikan relationship. Relasi baru hanya akan mempunyai 2 atribut, keduanya merupakan salinan primary key. Untuk 1:1 recursive relationship dengan optional participation pada 2 sisi, kita menciptakan relasi baru seperti yang telah diuraikan diatas.
● Superclass/subclass relationship types Menurut Connolly dan Begg ( 2005 , p467 ),untuk tiap superclass atau
subclass
relationship
dalam data model konseptual,
kita
31 mengidentifikasikan entitas superclass sebagai entitas parent dan entitas subclass sebagai entitas child. Terdapat banyak pilihan dalam merepresentasikan relationship sebagai salah satu atau lebih relasi – relasi. Pilihan yang paling sesuai tergantung dari sejumlah faktor seperti disjointnese dan participation constraint pada superclass / subclass relationship apakah subclass – subclass terlibat dalam distinct relationship dan jumlah participant – participant dalam superclass / subclass relationship.
● Many-to-many (*:*) binary relationship types Menurut Connolly dan Begg ( 2005 , p469 ), untuk tiap *:* binary relationship menciptakan relasi untuk merepresentasikan relationship dan meliputi atribut – atribut yang menjadi bagian dari relationship. Kita menyalin salinan primary key dari entitas yang berhubungan dalam relationship kedalam relasi baru. Untuk berlaku sebagai foreign key.
● Complex relationship types Menutur Connolly dan Begg ( 2005 , p470 ), untuk setiap complex relationship
menciptakan
sebuah
relasi untuk merepresentasikan
relationship dan termasuk semua atribut yang merupakan bagian dari relationship tersebut. Kita menyalin salinan primary key dari entitas yang berhubungan dalam complex relationship kedalam relasi baru, untuk berlaku sebagai foreign key.
32 ● Multi-valued attributes Menurut Connolly dan Begg ( 2005 , p471 ), menciptakan relasi yang merepresentasikan atribut – atribut multi-valued dan menyalin salinan primary key dari entitas owner kedalam relasi baru untuk menjadi foreign key.
Langkah 2.2 Validasi Model dengan Normalisasi Menurut Connolly dan Begg ( 2005 , p473 ), tujuannya adalah untuk memvalidasi relasi – relasi dalam model data konseptual menggunakan teknik normalisasi. Menurut Connolly dan Begg ( 2005 , p388 ), normalisasi adalah teknik untuk menghasilkan sekumpulan relasi – relasi dengan properti – properti yang diinginkan, sesuai dengan kebutuhan data – data yang diberikan oleh perusahaan. Tujuan dari normalisasi ini adalah untuk meminimalkan redudansi data (perulangan data) dan update anomalies, menciptakan representasi data, hubungan antar data dan contraint yang akurat, serta meningkatkan stabilitas. Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar atas relasi – relasi yang ada. Pada dasarnya, proses normalisasi ini dilakukan karena terjadinya redundansi data atau kejanggalan pengubahan (update anomaly). Menurut Connolly dan Begg ( 2005 , p391 ), update anomaly ada tiga jenis yaitu insert anomaly, delete anomaly, dan modification/update anomaly. Insert anomaly adalah kejanggalan yang terjadi terhadap sebuah table pada saat dilakukan penambahan suatu record, yaitu berupa pelanggaran terhadap integrity
33 constraint. Delete anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan informasi lain dari tabel tersebut. Modification/update anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan terhadap suatu nilai tertentu harus dilakukan lebih dari sekali. Hal ini amat memungkinkan terjadinya inkonsistensi data. Menurut Connolly dan Begg ( 2005 , p401 ), proses normalisasi meliputi langkah – langkah utama berikut : -
First Normal Form ( 1NF ), yang menghilangkan repeating groups
-
Second Normal Form ( 2NF ), yang menghilangkan partial dependency dalam primary key
-
Third Normal Form ( 3NF ), yang menghilangkan transitive dependencies dalam primary key
-
Boyce-Codd Normal Form ( BCNF ), yang menghilangkan anomaly – anomaly yang tersisa dari functional dependencies
Langkah 2.3 Mendefinisikan Kendala Integrity Menurut Connolly dan Begg ( 2005 , p474 ), tujuannya adalah memeriksa integrity constraint yang direpresentasikan dalam model data logical. Integrity constraint terdiri dari 5 jenis, yaitu : data yang dibutuhkan, attribute domain constraint, entity integrity, referential integrity, dan general constraint.
34 ● Data yang dibutuhkan Menurut Connolly dan Begg ( 2005 , p475 ), beberapa atribut harus selalu memiliki nilai yang valid. Dengan kata lain, atribut tersebut tidak boleh bernilai null. ● Attribute domain constraint Menurut Connolly dan Begg ( 2005 , p475 ), tiap atribut mempunyai domain, yaitu kumpulan nilai – nilai yang legal. Misalnya, ada 2 jenis kelamin yaitu ‘M’ atau ‘F’, jadi domain untuk atribut jenis kelamin adalah karakter string tunggal yang terdiri dari ‘M; atau ‘F’. Batasan ini harus diidentifikasikan ketika kita memilih domain atribut untuk model data. ● Multiplicity Menurut Connolly dan Begg ( 2005 , p475 ), multiplicity merepresentasikan batasan yang diletakkan pada relationship antara data di dalam basisdata. ● Entity integrity Menurut Connolly dan Begg ( 2005 , p475 ), primary key dari entitas tidak boleh bernilai null. Batasan ini harus betul – betul dipertimbangkan ketika kita mengidentifikasikan primary key untuk tiap tipe entitas. ● Referential integrity Menurut Connolly dan Begg ( 2005 , p475 ), foreign key menghubungkan tiap tuple dalam relasi child ke tuple dalam relasi parent yang meliputi nilai candidate key yang sesuai. Referential integrity berarti
35 bahwa jika foreign key memiliki nilai, maka nilai tersebut harus menunjuk pada tuple yang ada pada relasi parent. Menurut Connolly dan Begg ( 2005 , p476 ), terdapat 5 strategi untuk mempertahankan referential integrity pada saat penghapusan tuple pada relasi parent, yaitu : -
NO ACTION Mencegah penghapusan dari relasi parent jika terdapat tuple – tuple child yang ditunjuk.
-
CASCADE Ketika tuple parent dihapus, secara otomatis juga dihapus tuple – tuple child yang ditunjuk
-
SET NULL Ketika tuple parent dihapus, nilai foreign key dalam semua tuple – tuple child yang berhubungan secara otomastis diubah menjadi null.
-
SET DEFAULT Ketika tuple parent dihapus, nilai foreign key dalam semua tuple – tuple child yang berhubungan secara otomatis diubah menjadi nilai default-nya.
-
NO CHECK Ketika tuple parent dihapus, tidak melakukan apa – apa untuk menjamin referential integrity tetap terjaga.
36 ● General constraints Pengubahan – pengubahan pada entitas – entitas mungkin diatur oleh batasan – batasan yang memerintah transaksi ’real world’ yang direpresentasikan oleh pengubahan tersebut
Langkah 2.4 Menggabungkan Logical Data Model ke dalam Global Model (optional) Menurut Connolly dan Begg ( 2005 , p479 ), tujuannya adalah untuk merepresentasikan semua user views dari basisdata.
Langkah 2.5 Memeriksa untuk perkembangan lebih lanjut Menurut Connolly dan Begg ( 2005 , p490 ), tujuannya adalah menentukan apakah terdapat perubahan signifikan pada masa depan yang dapat diramalkan dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan tersebut.
37
Gambar 2.3 ERD Logical ( Sumber : Connolly dan Begg , 2005 , p489 )
2.1.7.3 Perancangan Basisdata Fisikal Menurut Connolly dan Begg ( 2005 , p439 ), perancangan fisik basisdata adalah proses membuat deskripsi dari implementasi basisdata pada secondary storage, mendeskripsikan relasi dasar, file organization, dan index yang digunakan untuk mendapatkan akses efisien pada data dan semua integrity
38 constraint yang berhubungan dan security measures. Tujuannya adalah untuk memutuskan bagaimana struktur logikal diimplementasikan (sebagai relasi dasar) secara fisik dalam DBMS yang dipilih. Menurut Connolly dan Begg ( 2005 ,
p496 ), langkah – langkah
perancangan fisik basisdata meliputi :
Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Menurut Connolly dan Begg ( 2005 , p497 ), tujuannya adalah untuk menghasilkan relational database schema dari data model logikal yang dapat diimplementasikan dalam DBMS yang dipilih. 3 aktifitas pada Step 3 :
Langkah 3.1 Merancang relasi – relasi dasar Menurut Connolly dan Begg ( 2005 , p498 ), tujuannya adalah untuk memutuskan
bagaimana merepresentasikan relasi – relasi dasar yang
diidentifikasikan dalam model data logikal dalam DBMS yang dipilih. Untuk tiap relasi yang diidentifikasi dalam model data logikal, kita mempunyai definisi yang terdiri dari : -
Nama relasi
-
Daftar atribut – atribut sederhana dalam golongan – golongan
-
Primary key dan alternate key dan foreign key jika ada
-
Referential
integrity
contraints
untuk
semua
foreign
keys
yang
diidentifikasikan Menurut Connolly dan Begg ( 2005 , p498 ), sedangkan dari data dictionary, dari tiap – tiap atribut kita juga mempunyai :
39 -
Domain-nya, yang terdiri dari tipe data, panjang, dan semua batasan dalam domain
-
Nilai default optional untuk atribut
-
Apakah atribut dapat mempunyai nilai nulls
-
Apakah atribut tersebut derived, maka harus dikomputasi
Langkah 3.2 Merancang Representasi untuk Data Turunan Menurut Connolly dan Begg ( 2005 , p499 ), tujuannya adalah untuk memutuskan bagaimana merepresentasikan semua data derived yang ada dalam model data logikal dalam DBMS yang dipilih. Atribut yang nilainya dapat dicari dengan memeriksa nilai – nilai dari atribut – atribut lainnya disebut derived atau calculated attribute.
Langkah 3.3 Merancang General Constraint Menurut Connolly dan Begg ( 2005 , p501 ), tujuannya adalah untuk merancang general constraint untuk DBMS yang dipilih.
Langkah 4. Merancang file organization dan indexes Menurut Connolly dan Begg ( 2005 , p501 ), tujuannya adalah untuk menentukan file organisasi yang optimal untuk menyimpan relasi – relasi dasar dan indeks – indeks yang dibutuhkan untuk mencapai performansi yang dapat diterima, dengan begitu, relasi dan tuple akan disimpan pada secondary storage. Terdapat beberapa factor yang dapat digunakan untuk mengukur efisiensi, yaitu :
40 -
Transaction throughput adalah jumlah transaksi yang dapat diproses dalam jangka waktu tertentu. Diukur pada kondisi peak.
-
Response time adalah waktu yang diperlukan untuk menyelesaikan satu transaksi. Dari pandangan
pengguna, kita sedapat
mungkin
ingin
meminimalkan response time. Response time ini biasanya dipengaruhi waktu untuk mengakses data yang diperlukan, system load, OS scheduling, communication delay. -
Disk storage adalah jumlah disk space yang dibutuhkan untuk menyimpan file – file basisdata. Para perancang sistem biasanya ingin meminimalkan disk storage yang digunakan.
Langkah 4.1 Menganalisa Transaksi Menurut Connolly dan Begg ( 2005 , p502 ), tujuannya adalah untuk mengerti fungsi dari transaksi yang akan diterapkan pada basisdata dan untuk menganalisa transaksi – transaksi yang penting.
Langkah 5. Merancang mekanisme keamanan Menurut Connolly dan Begg ( 2006 , p516 ), tujuannya adalah untuk merancang mekanisme keamanan untuk basisdata seperti yang ditentukan oleh user pada waktu tahap pengumpulan kebutuhan – kebutuhan dari system development lifecycle. Mekanisme kemanan yang dirancang dalam basisdata yaitu mekanisme keamanan sistem dan mekanisme keamanan data.
41 Langkah 6. Mempertimbangkan pengenalan redudancy control Menurut Connolly dan Begg ( 2006 , p519 ), tujuannya adalah untuk menentukan apakah pengenalan redundancy yang dikontrol dengan aturan – aturan normalisasi akan meningkatkan performansi sistem.
Langkah 7. Mengawasi dan mengendalikan sistem operasional Menurut Connolly dan Begg ( 2006 , p532 ), tujuannya adalah untuk mengawasi sistem operasional dan meningkatkan performansi dari sistem untuk memperbaiki keputusan perancangan yang tidak sesuai atau merefleksikan perubahan kebutuhan.
2.1.8
ER Modeling Terdapat beberpa konsep Model ER yang berupa : 2.1.8.1 Entity Type Menurut Connolly dan Begg ( 2005, p343) entity type adalah kelompok objek dengan properties yang sama, yang didefinisikan unutk perusahaan selama mempunyai keadaan yang independent. Entity type memepuyai kedaan yang independent dan dapat berupa objek-objek dengan keberadaan fisik atau objekobjek denga keberadaan konseptual.
2.1.8.2 Entity Occurrence Menurut Connolly dan Begg (2005, p346) relationship occurrence adalah penyatuan yang dapat diidentifikasikan secara unik, yang terdiri dari 1 occurrance dari tiap participating entity type
42 2.1.8.3 Atribut Menurut Connolly dan Begg (2005, p350) atribut adalah property dari entitas atau relationship type. Atribut domain adalah sekumpulan nilai-nilai yang diperbolehkan untuk satu atau lebih atribut. Atribut dapat diklasifikasikan menjadi a.
Simple Atribut yaitu yang terdiri dari satu komponen tunggal dengan keberadaan yang idependen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi
b.
Composite Atibut yaitu atribut yang terdiri dari beberpa komponen, dimana masing-masing komponen memilki keberdaan yang independen
c.
Single-valued Atribut yaitu atribut yang mempuyai nilai tunggal untuk setiap kejadian
d.
Multi-valued Atribut yaitu atribut yang mempuyai beberpa nilai untuk setiap kejadian
e.
Derived Atribut yaitu atribut yang memilki nilai yang dihasilakan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.
2.1.8.4 Key Menurut Connolly dan Begg ( 2005 , p352 ), candidate key adalah sekelompok atribut yang minimal dan secara unik mengidentifikasikan tiap occurrence dari entity type. Menurut Connolly dan Begg ( 2005 , p353 ), primary key adalah key yang dipilih untuk mengidentifikasikan secara unik tiap occurrence dari entity type.
43 Menurut Connolly dan Begg ( 2005 , p353 ), composite key adalah candidate key yang terdiri dari dua atau lebih atribut.
Gambar 2.4 ER Diagram
2.1.8.5 Structural constraint Tipe utama dari constraint dari relationship disebut multiplicity. Multiplicity adalah jumlah dari kejadian – kejadian yang mungkin dari sebuah tipe entitas yang terhubung pada kejadian tunggal dari tipe entitas yang berhubungan melalui relationship khusus. Tiga jenis relationship yang digunakan mengikuti enterprise constraint : •
Hubungan one-to-one (1:1)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-satu dan dapat pula member entitas yang satu ada yang tidak berhubungan dengan
44 member dari entitas yang berelasi dengannya dan entitas tersebut juga berelasi maksimal 1. Contoh : satu produk hanya memiliki satu bonus dan bonus hanya dimiliki oleh satu produk. Diasumsikan hanya produk tertentu saja yang mempunyai bonus dan bonusnya hanya satu.
Produk
1..1
has ►
1..1
Bonus
Gambar 2.5 Hubungan one-to-one (1:1)
•
Hubungan one-to-many (1:*)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satubanyak. Dimana sebuah member dari entitas dapat berhubungan dengan satu atau banyak member dari entitas yang lain dan member dari entitas yang lainnya berhubungan (bisa dari 0) sampai maksimal 1. Contoh : seorang kepala sekolah dapat memiliki 1 hingga banyak guru, tetapi seorang guru hanya memiliki satu dan hanya satu kepala sekolah.
1..1
has ►
1..*
KepalaSekolah
Gambar 2.6 Hubungan one-to-many (1:*)
Guru
45 •
Hubungan many-to-many (*:*)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah banyakbanyak. Member dari sebuah entitas dapat berelasi dengan entitas yang lain dengan maksimal multiplicity banyak (*) dan sebaliknya dengan relasi entitas yang berhubungan tersebut. Contoh : Pembeli dapat memilih 0 hingga banyak produk yang ingin dibeli, tetapi produk dapat dipilih untuk dibeli oleh 0 hingga banyak pembeli pada satu jenis produk.
Pembeli
0..*
Order ►
0..*
Produk
◄ OrderedBy
Gambar 2.7 Hubungan many-to-many (*:*)
2.1.9
Normalisasi Tujuan uatama dalam pengembangan model data logical pada sistem database relational adlah menciptakan representasi akurat suatu data, relationship anatar data dan batasan-batasannya. Untuk mencapai tujuan ini, maka harus ditetapkan sekumpulan relasi. 2.1.9.1 Pengetian Normalisasi Menurut Connolly dan Begg ( 2005 , p401 ), normalisasi adalah teknik formal untuk menganalisa relasi berdasarkan pada primary key (atau candidate key) dan functional dependencies.
46 2.1.9.2 Tahapan- tahapan Normalisasi Normalisasi memiliki Empat bentuk normal yang biasa digunakan yaitu : first normal form, second normal form dan third normal form dan beyce-codd normal form 2.1.9.2.1 UNF (Un-Normal Form) Menurut Connolly dan Begg ( 2005 , p402 ), proses normalisasi dimulai dari bentuk UNF (Un-Normal Form), yaitu tabel yang masih mengandung repeating group. Tabel UNF ini dibuat dengan mentransformasi data dari sumber informasi ( seperti formulir ) ke dalam tabel berbentuk baris dan kolom. 2.1.9.2.2
1NF (First Normal Form)
Menurut Connolly dan Begg ( 2005 , p403 ), pada bentuk normal pertama ( First Normal Form – 1NF ), sebuah relasi dimana pada setiap sel ( perpotongan baris dan kolom ) jika dan hanya jika mengandung satu nilai, setiap sel mengandung nilai atomik ( single value ). Untuk menjadikan bentuk tidak normal menjadi normal pertama dengan mengidentifikasikan dan menghilangkan repeating groups yang ada di dalam tabel. Repeating group adalah sebuah atau sekumpulan atribut dalam tabel yang memiliki multiple values untuk single occurrence dari atribut key yang terpilih untuk tabel tersebut. 2.1.9.2.3
2NF (second Normal Form)
Menurut Connolly dan Begg ( 2005 , p407 ), sebuah tabel disebut berada pada bentuk normal kedua ( 2NF ) jika dan hanya jika setiap atribut bukan primary key ( PK ) tergantung sepenuhnya pada PK. Untuk mengetahui apakah 1NF telah berada pada 2NF maka tentukan PK dan funtional dependency.
47 2.1.9.2.4
3NF (Third Normal Form)
Menurut Connolly dan Begg ( 2005 , p408 ), sebuah tabel disebut berada pada bentuk normal ketiga jika dan hanya jika tidak ada atribut bukan primary key yang bergantung kepada atribut bukan primary key lainnya. Sebuah tabel yang mengandung atribut bukan PK yang tergantung pada atribut PK lainnya disebut transitive dependency. Dengan kata lain sebuah tabel disebut berada pada 3NF jika dan hanya jika tidak mengandung transitive dependency. 2.1.9.2.5
BCNF(Boyce-Codd Normal Form)
Menurut Connolly dan Begg ( 2005 , p419 ), suatu relasi dianggap sebagai bentuk normal BCNF jika dan hanya jika setiap determinant adalah candidate key. Untuk mengetahui apakah suatu tabel sudah berada pada bentuk normal BCNF maka harus dilakukan analisa atas functional dependency dari sebuah tabel. 2.1.10 Tools Yang Digunakan Untuk menyelesaikan suatu masalah dengan cara mendekomposisi system ke dalam komponen yang lebih kecil dengan tujuan untuk mempelajari bagaimana komponen-komponen tersebut bekerja dan saling berinteraksi maka kita memerlukan tool-tool yang dapat mencerminkan proses. Adapun beberapa tool yaitu : 2.1.10.1 Data Flow Diagram Menurut Hall ( 2001 , p69 ), DFD yang juga disebut dengan Diagram Arus Data, adalah diagram yang menyajikan rangkaian simbol - simbol untuk mencerminkan proses, sumber-sumber data, arus data, dan entitas dalam sebuah sistem pada tingkatan rinci yang berbeda.
48 DFD pertama kali diperkenalkan sebagai modeling tools Tom Demarco ( 1978 ), Gane dan Sarson ( 1979 ) dengan menggunakan pendekatan metode analisis sistem terstrukstur (structured system analysis method). DFD juga dapat digunakan untuk merepresentasikan suatu sistem yang otomatis maupun manual dengan menggunakan gambar yang berbentuk jaringan grafik. Tingkatan Diagram Pada DFD : 1
Diagram Konteks
•
Merupakan level tertinggi pada DFD yang menggambarkan seluruh output atau input ke sistem
•
Memberikan gambaran tentang keseluruhan sistem
•
Terminal yang memberikan masukan kepada sistem disebut source, sedangkan yang menerima keluaran dari sistem disebut sink
•
Hanya ada satu proses didalam diagram konteks
•
Tidak boleh ada proses penyimpanan data (data store)
2. Diagram Nol •
Memperlihatkan proses penyimpanan data (data store) yang digunakan
•
Untuk proses yang tidak rinci lagi pada level selanjutnya, tambahkan tanda * pada akhir nomor proses
•
Keseimbangan antara input dan output pada diagram nol dan diagram konteks harus terpelihara
49 Simbol-simbol dalam DFD adalah : Tabel 2.1 Tabel Simbol DFD External entity atau terminal
Proses
Penyimpanan data atau data storage
Aliran data atau Data Flow
2.1.10.2 State Transition Diagram (STD) Menurut Pressman ( 2001 , p302 ), State Transition Diagram merupakan suatu diagram yang menggambarkan bagaimana state dihubungkan dengan state yang lain pada satu waktu. State Transition Diagram menunjukkan bagaimana sistem bekerja sebagai akibat dari kejadian eksternal. Untuk melakukan hal itu, State Transition Diagram menampilkan model yang bermacam-macam dari tindakan sebuah sistem dan dibuat dari state ke state. Komponen dasar dari State Transition Diagram adalah :
50 1.
: menyatakan state atau kondisi dari suatu sistem. State terdiri dari dua macam, yaitu initial state / state awal dan final state / state akhir. Final state dapat terdiri atas beberapa state, tetapi initial state tidak boleh lebih dari satu.
2.
: menyatakan
perubahan
kondisi
dari
suatu
sistem.
Digambarkan untuk menghubungkan keadaan sistem yang berkaitan. 3. Kondisi dan Aksi Kondisi : menyatakan suatu kejadian pada lingkungan eksternal yang dapat dideteksi oleh suatu sistem. Misalnya : suatu sinyal / data. Aksi : menyatakan sesuatu yang dilakukan oleh sistem apabila terjadi perubahan state / merupakan suatu reaksi terhadap kondisi. Aksi akan menghasilkan output, message display pada monitor dan menghasilkan kalkulasi.
2.1.10.3 Bagan Alir Dokumen (Document FlowChart) Document FlowChart digunakan untuk menggambarkan bagan alir dokumen suatu sistem. Berikut adalah simbol – simbol standar beserta keterangannya untuk mengambarkan bagan alir dokumen : Tabel 2.2 Tabel Simbol Document FlowChart Lambang
Keterangan Dokumen. Simbol ini digunakan untuk menggambarkan semua jenis dokumen, yang merupakan formulir yang diunakan untuk merekam data terjadinya suatu transaksi
51 Dokumen dan tembusannya. Simbol ini digunakan untuk menggambarkan dokumen asli dan tembusannya. Nomor lembar dokumen dicantumkan di sudut kanan atas
Catatan. Simbol ini digunakan untuk menggambarkan catatan akuntansi yang digunakan untuk mencatat data yang direkam sebelumnya di dalam dokumen atau formulir Penghubung pada halaman yang sama (on-page connector). Dalam menggambarkan bagan alir, arus dokumen dibuat mengalir dari atas ke bawah dan dari kiri ke kanan. Karena keterbatasan ruang halaman kertas untuk menggambar, maka diperlukan simbol penghubung ini. Penghubung pada halaman yang berbeda (off-page connector). Jika untuk menggambarkan bagan alir suatu sistem akuntansi diperlukan lebih dari satu halaman, simbol ini harus digunakan untuk menunjukkan kemana dan bagaimana bagan alir terkait satu dengan lainnya. Kegiatan manual. Simbol ini digunakan untuk menggambarkan kegiatan manual seperti : menerima order dari pembeli, mengisi formulir dan kegiatan lainnya Keterangan, komentar. Simbol ini memungkinkan ahli sistem menambahkan keterangan untuk memperjelas pesan yang disampaikan dalam bagan alir
Arsip permanen. Simbol ini digunakan untuk menggambarkan arsip permanen yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem akuntansi yang bersangkutan Keputusan. Simbol ini menggambarkan keputusan yang harus dibuat dalam proses pengolahan data. Keputusan yang dibuat ditulis di dalam simbol Garis alir (flowline). Simbol ini menggambarkan arah proses pengolahan data. Anak panah tidak digambarkan jika arus dokumen mengarah ke bawah dan ke kanan. Jika arus dokumen mengalir ke atas atau ke kiri, anak panah perlu dicantumkan
52 Persimpangan garis alir. Jika dua garis alir bersimpangan, untuk menunjukkan arah masing – masing garis, salah satu garis dibuat sedikit melengkung tepat pada persimpangan ke dua garis tersebut Pertemuan garis alir. Simbol ini digunakan jika dua garis alir bertemu dan salah satu garis mengikuti arus garis lainnya Mulai/berakhir (terminal). Simbol ini untuk menggambarkan awal dan akhir suatu sistem akuntansi Masuk ke sistem. Karena kegiatan di luar sistem tidak perlu digambarkan dalam bagan alir, maka diperlukan simbol untuk menggambarkan masuk ke sistem yang digambarkan dalam bagan alir Keluar ke sistem lain. Karena kegiatan di luar sistem tidak perlu digambarkan dalam bagan alir, maka diperlukan simbol untuk menggambarkan keluar ke sistem lain
Perbedaan data flow dengan flowchart : 1.
Proses dalam data flow dapat dioperasikan secra parallel,sehingga dapat dieksekusi secara terus menerus, sedangkan proses pada data flow dapat dieksekusi sekali
2.
Diagram data flow menunjukan aliran data melalui system
3.
data flow diagram dapat menunjukan proses yang memiliki perbedaan waktu.
53 2.2
Teori-Teori Khusus
2.2.1 Persediaan Menurut Mulyadi ( 2001 , p553 ), sistem persediaan bertujuan untuk mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini berkaitan erat dengan sistem penjualan, sistem retur penjualan, sistem pembelian, sistem retur pembelian, dan sistem akuntansi biaya produksi. 2.2.1.1 Jenis-jenis persediaan Menurut Sofjan Assauri (1999, 221), persediaan yang terdapat di dalam perusahaan dapat di bedakan menurut berbagai cara antara lain sebagai berikut: 1) Menurut fungsinya, persediaan dapat dibedakan atas : a) Batch Stock atau Lot Size Inventory Adalah persediaan yang diadakan karena kita membeli atau membuat bahan-bahan atau barang-barang dalam jumlah yang lebih besar daripada jumlah yang dibutuhkan pada saat itu. Jadi dalam hal ini pembelian atau pembuatan yang dilakukan untuk jumlah yang besar, sedangkan penggunaan atau pengeluaran dalam jumlah kecil. Terjadinya persediaan karena pengadaan bahan atau barang yang dilakukan lebih banyak daripada yang dibutuhkan. b) Fluctuation Stock Adalah persediaan yang diadakan untuk menghadapi fluktuasi permintaan konsumen yang tidak dapat diramalkan. c) Anticipation Stock Adalah persediaan yang diadakan untuk menghadapi fluktuasi permintaan yang dapat diramalkan berdasarkan pola musiman yang
54 terdapat dalam satu tahun dan untuk menghadapi penggunaan atau penjualan yang meningkat.
2) Menurut jenis dan posisi barang tersebut didalam urutan pengerjaan produk, persediaan dapat dibagi atas : a) Persediaan bahan baku (Raw Materials) Yaitu persediaan dari barang-barang berwujud yang digunakan dalam proses produksi. Contoh : kapas dipintal menjadi benang, benang diolah menjadi kain atau kaos. b) Persediaan bagian produk atau parts yang dibeli (purchased parts / komponen stock) Yaitu persediaan barang-barang yang terdiri dari parts yang diterima dari perusahaan lain, yang dapat secara langsung di assembling dengan parts lain, tanpa melalui proses produksi sebelumnya. Jadi bentuk barang yang merupakan parts tidak mengalami perubahan dalam operasi. Misalnya pabrik mobil, dimana dalam hal ini bagian-bagian (parts) dari mobil tersebut tidak diprodusir dalam pabrik mobil, tetapi diprodusir oleh perusahaan lain, dan kemudian di assembling menjadi barang yakni mobil. c) Persediaan barang-barang pembantu atau barang-barang pelengkap (supplies stock) Yaitu
persediaan
barang-barang
atau
bahan-bahan
yang
diperlukan dalam proses produksi untuk membantu berhasilnya produksi atau yang dipergunakan dalam bekerjanya suatu perusahaan, tetapi tidak
55 merupakan bagian atau komponen dari barang jadi. Misalnya minyak solar dan minyak pelumas adalah hanya merupakan bahan pembantu. d) Persediaan barang setengah jadi atau barang dalam proses (work in process / progress) Yaitu persediaan barang-barang yang keluar dari tiap-tiap bagian dalam satu pabrik atau bahan-bahan yang telah diolah menjadi suatu bentuk, tetapi lebih perlu diproses kembali untuk kemudian menjadi barang jadi. e) Persediaan barang jadi (finished goods stock) Yaitu persediaan barang-barang yang telah selesai diproses atau diolah dalam pabrik dan siap untuk dijual kepada pelanggan atau perusahaan lain.
2.2.1.2 Biaya-biaya yang timbul akibat adanya persediaan Menurut Hani Handoko (2000:336), ada beberapa biaya-biaya yang timbul dari adanya persediaan antara lain : 1.
Biaya penyimpanan Biaya penyimpanan (holding costs / carrying cost) terdiri atas biayabiaya yang bervariasi secara langsung dengan kuantitas persediaan biaya penyimpanan per periode akan semakin banyak apabila kuantitas bahan baku yang di pesan semakin banyak, atau rata-rata persediaan semakin tinggi. Biaya-biaya yang termasuk sebagai biaya penyimpanan adalah :
56 1. Biaya fasilitas-fasilitas penyimpanan (termasuk penerangan, pemanas, atau pendingin). 2. Biaya modal. 3. Biaya keusangan 4. Biaya perhitungan fisik dan konsiliasi laporan 5. Biaya asuransi 6. Biaya pajak persediaan 7. Biaya pencurian, pengrusakan, dan perampokan 8. Biaya penanganan persediaan
2.
Biaya pemesanan Setiap kali suatu bahan dipesan, perusahaan menanggung biaya pemesanan. Biaya pemesanan secara terperinci meliputi : 1. Pemrosesan pesanan dan biaya ekspedisi 2. Upah 3. Biaya telepon 4. Pengeluaran surat menyurat 5. Biaya pengepakan 6. Biaya pemeriksaan 7. Biaya pengiriman kegudang
57 3.
Biaya penyiapan Bila bahan-bahan tidak dibeli, tetapi diproduksi sendiri”dalam pabrik” perusahaan. Perusahaan menghadapi biaya penyiapan (setup costs) untuk memproduksi komponen tertentu. Biaya-biaya ini terdiri dari : 1. Biaya mesin menganggur 2. Biaya persiapan tenaga kerja langsung 3. Biaya scheduling 4. Biaya ekspedisi
4.
Biaya kehabisan atau kekurangan bahan Dari semua biaya-biaya yang berhubungan dengan tingkat persediaan, biaya kekurangan (shortage costs) adalah yang paling sulit diperkirakan. Biaya ini timbul bilamana persediaan tidak mencukupi adanya permintaan bahan. Biaya-biaya yang termasuk biaya kekurangan adalah sebagai berikut : 1. Kehilangan penjualan 2. Kehilangan pelanggan 3. Biaya pemesanan khusus 4. Biaya ekspedisi 5. Selisih harga 6. Terganggunya operasi 7. Tambahan pengeluaran kegiatan manajerial
58 2.2.1.3 Fungsi Persediaan Menurut Sofjan Assauri (1999:230), fungsi persediaan yang efektif adalah: 1.
Memperoleh bahan-bahan Yaitu menetapkan prosedur untuk memperoleh suplai yang cukup
dari bahan-bahan yang dibutuhkan baik kuantitas maupun kualitas. 2.
Menyimpan dan memelihara bahan-bahan dalam persediaan Yaitu mengadakan suatu system penyimpanan untuk memelihara
dan melindungi bahan-bahan yang telah dimasukkan ke dalam persediaan. 3.
Pengeluaran bahan-bahan Yaitu menetapkan suatu pengaturan atas pengeluaran dan
penyampaian bahan-bahan dengan tepat pada saat serta tempat dimana dibutuhkan. 4.
Meminimalisasi investasi dalam bentuk bahan atau barang
(mempertahankan persediaan dalam jumlah yang optimum setiap waktu). 2.2.2
Penjualan Menurut Mulyadi ( 2001 , p202 ), kegiatan penjualan terdiri dari penjualan
barang dan jasa, baik secara kredit maupun secara tunai. Dalam transaksi penjualan kredit, jika order dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Dalam sistem penjulan secara tunai, barang atau jasa baru diserahkan oleh perusahaan kepada pembeli jika perusahaan telah menerima kas dari pembeli.
59 Menurut Mulyadi(2001,p226), Transaksi retur penjualan terjadi jika perusahaan menerima pengembalian barang dari pelanggan. Pengembalian barang oleh pelanggan harus diotorisasi oleh fungsi penjualan dan diterima oleh fungsi penerimaan. Fungsi yang terkait dalam melaksanakan transaksi retur penjualan adalah : 1. Fungsi penjualan Fungsi ini bertanggung jawab atas penerimaan pemberitahuan mengenai pengembalian barang yang telah dibeli oleh pembeli. Otorisasi penerimaan kembali barang yang telah dijual tersebut dilakukan dengan cara membuat memo kredit yang dikirimkan kepada fungsi penerimaan. 2. Fungsi penerimaan Fungsi ini bertanggung jawab atas penerimaan barang berdasarkan otorisasi yang terdapat dalam memo kredit yang diterima dari fungsi penjualan. 3. Fungsi gudang Fungsi ini bertanggung jawab atas penyimpanan kembali barang yang diterima dari retur penjualan setelah barang tersebut diperiksa oleh fungsi penerimaan. Barang yang diterima dari transaksi retur penjualan ini dicatat oleh fungsi gudang dalam kartu gudang. 4. Fungsi akuntansi Fungsi ini bertanggung jawab atas pencatatan transaksi retur penjualan ke dalam jurnal umum dan pencatatan berkurangnya piutang dan bertambahnya persediaan akibat retur penjualan dalam kartu piutang dan kartu persediaan. Disamping itu, fungsi ini juga bertanggung jawab untuk mengirimkan memo kredit kepada pembeli yang bersangkutan.
60 Menurut Mulyadi(2001,p234), jaringan prosedur dalam sistem retur penjualan adalah sebagai berikut : 1. Prosedur pembuatan memo kredit Fungsi penjualan membuat memo kredit yang memberikan perintah kepada fungsi penerimaan untuk menerima barang dari pembeli tersebut dan kepada fungsi akuntansi untuk pencatatan pengurangan piutang kepada pembeli yang bersangkutan. 2. Prosedur penerimaan barang Fungsi penerimaan menerima dari pembeli berdasarkan perintah dari memo kredit yang diterima dari fungsi penjualan. Atas penerimaan barang tersebut fungsi penerimaan membuat laporan penerimaan barang untuk melampiri memo kredit yang dikirim ke fungsi akuntansi. 3. Prosedur pencatatan retur penjualan Dalam prosedur ini transaksi berkurangnya piutang dagang dan pendapatan penjualan akibat dari transaksi retur penjualan dicatat oleh fungsi akuntansi ke dalam jurnal umum atau jurnal retur penjualan dan ke dalam buku pembantu piutang. Dalam prosedur ini pula berkurangnya harga pokok penjualan dan bertambahnya harga pokok persediaan dicatat oleh fungsi akuntansi ke dalam jurnal umum dan dalam buku pembantu persediaan.
Menurut Mulyadi ( 2001 , p204 ), fungsi yang terkait pada penjualan secara kredit adalah : 1. Fungsi penjualan
61 Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk menerima surat order dari pembeli, mengedit order dari pelanggan untuk menambahkan informasi yang belum ada pada surat order tersebut (seperti spesifikasi barang dan rute pengiriman), meminta otorisasi kredit, menentukan tanggal pengiriman dan dari gudang nama barang akan dikirim, dan mengisi surat order pengiriman. Fungsi ini juga bertanggung jawab untuk membuat “back order” pada saat diketahui tidak tersedianya persediaan untuk memenuhi order dari pelanggan. 2. Fungsi kredit Fungsi ini berada di bawah fungsi keuangan yang dalam transaksi penjualan kredit, bertanggung jawab untuk meneliti status kredit pelanggan dan memberikan otorisasi pemberian kredit kepada pelanggan. Karena hampir semua penjualan dalam perusahaan manufaktur merupakan penjualan kredit, maka sebelum order dari pelanggan dipenuhi, harus lebih dahulu diperoleh otorisasi penjualan kredit dari fungsi kredit. Jika penolakan pemberian kredit seringkali terjadi, pengecekan status kredit perlu dilakukan sebelum fungsi penjualan mengisi surat order penjualan. Untuk mempercepat pelayanan kepada pelanggan, surat order pengiriman dikirim langsung ke fungsi pengiriman sebelum fungsi penjualan memperoleh otorisasi kredit dari fungsi kredit. Namun, tembusan kredit harus dikirimkan ke fungsi kredit untuk mendapatkan persetujuan kredit dari fungsi tersebut. Dalam hal otorisasi kredit tidak dapat diberikan, fungsi penjualan memberitahu fungsi pengiriman untuk membatalkan pengiriman barang kepada pelanggan.
62 3. Fungsi gudang Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk menyimpan barang dan menyiapkan barang yang dipesan oleh pelanggan, serta menyerahkan barang ke fungsi pengiriman. 4. Fungsi pengiriman Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk menyerahkan barang atas dasar suatu order pengiriman yang diterima dari fungsi penjualan. Fungsi ini bertanggung jawab untuk menjamin bahwa tidak ada barang yang keluar dari perusahaan tanpa ada otorisasi dari yang berwenang. Otorisasi ini dapat berupa surat order pengiriman yang telah ditandatangani oleh fungsi penjualan, memo debit yang ditandatangani oleh fungsi pembelian untuk barang yang dikirimkan kembali kepada pemasok (retur pembelian), surat perintah kerja dari fungsi produksi mengenai penjualan / pembuangan aktiva tetap yang sudah tidak dipakai lagi. 5. Fungsi penagihan Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk membuat dan mengirimkan faktur penjualan kepada pelanggan, serta menyediakan copy faktur bagi kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi. 6. Fungsi akuntansi Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk mencatat piutang yang timbul dari transaksi penjualan kredit dan membuat serta mengirimkan pernyataan piutang kepada para debitur, serta membuat
63 laporan penjualan. Di samping itu, fungsi ini juga bertanggung jawab untuk mencatat harga pokok persediaan yang dijual ke dalam kartu persediaan.
Menurut Mulyadi ( 2001 , p219 ), sistem dan prosedur yang bersangkutan dengan sistem penjualan kredit adalah : a. Prosedur order penjualan Dalam prosedur ini, fungsi penjualan menerima order dari pembeli dan menambahkan informasi penting pada surat order dari pembeli. Fungsi penjualan kemudian membuat surat order pengiriman dan mengirimkannya kepada berbagai fungsi yang lain untuk memungkinkan fungsi tersebut memberikan kontribusi dalam melayani order dari pembeli. b. Prosedur persetujuan kredit Dalam prosedur ini, fungsi penjualan meminta persetujuan penjualan kredit kepada pembeli tertentu dari fungsi kredit. c. Prosedur pengiriman Dalam prosedur ini, fungsi pengiriman mengirimkan barang kepada pembeli sesuai dengan informasi yang tercantum dalam surat order pengiriman yang diterima dari fungsi pengiriman. d. Prosedur penagihan Dalam prosedur ini, fungsi penagihan membuat faktur penjualan dan mengirimkannya kepada pembeli. Dalam metode tertentu faktur penjualan dibuat oleh fungsi penjualan sebagai tembusan pada waktu bagian ini membuat surat order pengiriman.
64 e. Prosedur pencatatan puitang Dalam prosedur ini, fungsi akuntansi mencatat tembusan faktur penjualan ke dalam kartu piutang atau dalam metode pencatatan tertentu mengarsipkan dokumen tembusan menurut abjad yang berfungsi sebagai catatan piutang. f. Prosedur distribusi penjualan Dalam prosedur ini, fungsi akuntansi mendistribusikan data penjualan menurut informasi yang diperlukan oleh manajemen. g. Prosedur pencatatan harga pokok penjualan Dalam prosedur ini, fungsi akuntansi mencatat secara periodik total harga pokok produk yang dijual dalam periode akuntansi tertentu.
