6
BAB 2 LANDASAN TEORI 2.1 Pengertian Basis Data Ada beberapa macam definisi tentang basis data yang disampaikan oleh beberapa pakar. Definisi tersebut antara lain yaitu : Menurut O’Brien (2002, p.166) basis data merupakan kumpulan data dari beberapa file dokumen yang terhubung secara logis. Menurut Date (2000, p.10) basis data merupakan kumpulan data tetap (data yang hampir tidak mengalami perubahan), yang digunakan oleh sistem aplikasi di beberapa perusahaan. Menurut Connolly & Begg (2002, p.14) basis data adalah kumpulan data yang terhubung secara logis, dan merupakan deskripsi dari data itu sendiri, yang dirancang untuk mempermudah proses pencarian informasi yang dibutuhkan oleh perusahaan. Dari beberapa definisi tentang basis data yang telah disebutkan diatas, dapat disimpulkan bahwa basis data merupakan kumpulan data yang terhubung secara logis dan digunakan pada sistem aplikasi perusahaan, yang dapat mempermudah proses pencarian informasi. 2.1.1 Database Management System (DBMS) DBMS adalah sebuah sistem perangkat lunak yang memungkinkan pengguna untuk dapat mendefinisikan, menciptakan, memelihara, dan mengontrol akses ke basis data (Connolly & Begg, 2002, p.16). DBMS dapat berinteraksi dengan pengguna program aplikasi dan basis data. Secara khusus, fasilitas-fasilitas yang disediakan oleh DBMS yaitu :
7
•
DBMS memungkinkan pengguna untuk dapat mendefinisikan basis data, yang biasanya menggunakan DDL (Data Definition Language).
•
DBMS memungkinkan pengguna untuk dapat memasukkan (insert), memperbaharui (update), dan memperoleh kembali (retrieve) data dari basis data, yang biasanya menggunakan DML (Data Manipulation Language).
•
DBMS menyediakan akses terkontrol ke basis data, seperti sistem keamanan (security system), sistem integritas (integrity system), dan katalog yang dapat diakses oleh pengguna (user accessible catalog).
2.2 Database Language Sebuah data sublanguage terdiri dari dua bagian, yaitu DDL (Data Definition Language) dan DML (Data Manipulation Language). DDL digunakan untuk menspesifikasikan skema basis data, sedangkan DML digunakan untuk membaca dan memperbaharui basis data. 2.2.1 DDL (Data Definition Language) DDL merupakan bahasa yang memungkinkan DBA (Database Administrator) atau pengguna untuk menciptakan dan memberi nama suatu entiti, atribut, serta hubungan-hubungan yang dibutuhkan untuk aplikasi, berikut dengan batasan-batasan keamanan dan integritasnya (Connolly & Begg, 2002, p.40). DDL dapat digunakan untuk mendefinisikan dan memodifikasi skema basis data, tetapi tidak dapat digunakan untuk memanipulasi data.
8
2.2.2 DML (Data Manipulation Language) DML merupakan bahasa yang menyediakan sekumpulan operasi untuk mendukung operasi dasar manipulasi data di dalam basis data (Connolly & Begg, 2002, p.41). Pada umumnya operasi manipulasi data mencakup : •
Memasukkan data baru ke dalam basis data
•
Memodifikasi data yang telah disimpan di dalam basis data
•
Mencari data yang terdapat di dalam basis data
•
Menghapus data dari basis data
2.3 Teknik Analisis dan Perancangan Basis Data Sistem informasi adalah sumber-sumber yang dapat mendukung kegiatan pengumpulan, pengaturan, pengawasan, dan penyebaran informasi di dalam suatu perusahaan (Connolly & Begg, 2002, p.270). Sebuah sistem informasi yang berbasis komputer terdiri dari basis data, perangkat lunak untuk basis data, perangkat lunak untuk aplikasi, perangkat keras komputer, dan personil yang menggunakan serta membangun sistem tersebut. Basis data merupakan komponen terpenting di dalam sebuah sistem informasi organisasi yang sangat luas. Oleh karena itu, siklus hidup sistem informasi suatu organisasi sangat berhubungan dengan siklus hidup sistem basis data yang mendukung sistem informasi tersebut. Secara khusus, tahap-tahap dalam siklus hidup sistem informasi meliputi perencanaan (planning), pengumpulan dan analisis kebutuhan (requirement collection and analysis), perancangan (design), perancangan bentuk dasar (prototyping), implementasi (implementation), uji coba (testing), konversi (conversion), dan pemeliharaan operasional (operational maintenance).
Sebagai komponen terpenting di dalam sistem informasi, maka siklus hidup basis data harus diasosiasikan dengan siklus hidup sistem informasi. Skema dibawah ini menunjukkan tahap-tahap yang terdapat dalam siklus hidup sistem basis data.
Gambar 2.1 Tahap-Tahap Siklus Hidup Aplikasi Basis Data (Connolly & Begg, 2002, p.272)
10
2.3.1 Perencanaan Basis Data (Database Planning) Perencanaan basis data adalah tahap perencanaan mengenai bagaimana seluruh tahap dalam siklus hidup aplikasi basis data dapat direalisasikan secara efektif dan efisien. Perencanaan basis data harus terintegrasi dengan strategi sistem informasi organisasi secara keseluruhan. Ada tiga hal utama yang harus dilakukan dalam membuat sebuah strategi sistem informasi, yaitu : •
Mengidentifikasikan tujuan dan rencana perusahaan, serta menentukan kebutuhan-kebutuhan sistem informasi.
•
Mengevaluasi sistem informasi yang ada saat ini untuk mengetahui kekuatan dan kelemahan sistem tersebut.
•
Memprediksi kesempatan dalam bidang teknologi informasi yang mungkin dapat menghasilkan keuntungan yang kompetitif. Langkah awal yang penting dalam tahap perencanaan basis data adalah
menentukan dengan jelas mission statement untuk proyek basis data. Selain itu perencanaan basis data juga harus mencakup pengembangan umum mengenai bagaimana data dikumpulkan, bagaimana data dispesifikasikan, dokumen penting apa saja yang dibutuhkan, serta bagaimana memproses perancangan dan implementasi. 2.3.2 Pendefinisian Sistem (System Definition) Pendefinisian sistem menggambarkan ruang lingkup dari aplikasi basis data dan user view utama. Sebelum mencoba merancang sebuah aplikasi basis data, hal pertama yang harus dilakukan adalah mengidentifikasi batasanbatasan sistem dan bagaimana sistem tersebut akan berinteraksi dengan bagianbagian sistem informasi organisasi lainnya.
11
User view didefinisikan sebagai kebutuhan aplikasi basis data yang berasal dari tugas-tugas yang ada atau area aplikasi perusahaan. Sebuah aplikasi basis data dapat memiliki satu user view atau lebih. 2.3.3 Pengumpulan dan Analisis Kebutuhan (Requirement Collection and Analysis) Proses pengumpulan dan analisis kebutuhan meliputi kegiatan mengumpulkan dan menganalisis informasi tentang bagian-bagian organisasi yang akan didukung oleh aplikasi basis data, kemudian menggunakan informasi ini untuk mengidentifikasi kebutuhan pengguna sehubungan dengan sistem baru. Teknik yang digunakan dalam tahap ini adalah teknik fact-finding. Pendekatan utama untuk menangani kebutuhan akan sebuah aplikasi basis data dengan beberapa user view, yaitu : •
Centralized Approach Dalam pendekatan ini, kebutuhan setiap user view digabungkan ke dalam satu set kumpulan kebutuhan untuk aplikasi basis data yang baru.
•
View Integration Approach Dalam pendekatan ini, kebutuhan setiap user view digunakan untuk membangun sebuah model data yang terpisah untuk merepresentasikan user view tersebut.
2.3.4 Perancangan Basis Data (Database Design) Perancangan basis data merupakan proses pembuatan rancangan sebuah basis data yang dapat mendukung kegiatan operasional perusahaan dan tujuan perusahaan. Ada dua pendekatan utama untuk merancang sebuah basis data, yaitu :
12
•
Bottom-Up Pendekatan bottom-up cocok untuk perancangan sebuah basis data sederhana, dengan jumlah atribut yang relatif kecil. Namun pendekatan ini sulit untuk diterapkan di dalam rancangan basis data yang lebih kompleks dengan jumlah atribut yang lebih besar, karena akan sulit untuk membangun semua ketergantungan fungsional diantara atribut-atribut.
•
Top-Down Strategi yang lebih cocok untuk membuat sebuah basis data yang lebih kompleks adalah pendekatan top-down. Pendekatan ini dimulai dengan mengembangkan model data yang mengandung beberapa entity tingkat tinggi beserta hubungan-hubungannya, kemudian dilanjutkan dengan mengidentifikasi entity-entity tingkat rendah, hubungan-hubungannya, dan mengasosiasikan atribut-atribut yang berhubungan.
2.3.5 Pemilihan DBMS (DBMS Selection) Pemilihan DBMS bertujuan untuk menentukan DBMS yang tepat untuk mendukung aplikasi basis data. Langkah-langkah utama dalam proses pemilihan DBMS yaitu : •
Menentukan masa referensi studi
•
Mengurutkan dua atau tiga produk secara singkat
•
Mengevaluasi produk
•
Membuat laporan tentang pilihan yang direkomendasikan
13
2.3.6 Perancangan Aplikasi (Application Design) Perancangan aplikasi merupakan proses perancangan tatap muka pengguna dan program-program aplikasi yang akan menggunakan serta memproses basis data. Basis data diciptakan untuk mendukung aplikasi, sehingga harus ada arus informasi antara rancangan aplikasi dengan rancangan basis data. Maka dari itu, pada banyak kasus adalah tidak mungkin untuk melengkapi rancangan aplikasi jika rancangan basis data belum selesai. 2.3.6.1 Perancangan Transaksi Transaksi merupakan aksi, atau sekumpulan aksi, yang dilayani oleh seorang pengguna tunggal atau program aplikasi, yang akan mengakses atau mengubah isi basis data. Ada tiga tipe utama transaksi, yaitu : a. Retrieval transactions, yang digunakan untuk memperoleh kembali data yang telah disimpan. b. Update transactions, yang digunakan untuk memasukkan data baru, menghapus data lama, atau memodifikasi data yang sudah disimpan di dalam basis data. c. Mixed transactions, yang mencakup kegiatan pencarian data dan pembaharuan data. 2.3.7 Perancangan Bentuk Dasar (Prototyping) Perancangan bentuk dasar adalah proses pembangunan sebuah model kerja dari sebuah aplikasi basis data. Ada dua strategi perancangan bentuk dasar yang digunakan saat ini, yaitu :
14
•
Requirement prototyping, yang menggunakan sebuah prototype untuk menentukan kebutuhan-kebutuhan dari aplikasi basis data yang diusulkan. Apabila semua kebutuhan telah selesai ditentukan maka prototype tersebut tidak akan digunakan lagi.
•
Evolutionary prototyping, yang digunakan untuk tujuan yang sama dengan requirement prototyping. Perbedaannya adalah prototype tersebut masih akan digunakan lagi.
2.3.8 Implementasi (Implementation) Implementasi adalah realisasi fisik dari proses perancangan basis data dan
perancangan
aplikasi.
Penerapan
basis
data
dilakukan
dengan
menggunakan DDL dari DBMS yang dipilih. 2.3.9 Konversi Data dan Muatan (Data Conversion and Loading) Konversi data dan muatan merupakan proses pemindahan data-data yang ada ke dalam basis data baru, dan mengubah setiap aplikasi yang sudah ada untuk dijalankan pada basis data baru. Tahap ini hanya dibutuhkan ketika sistem baru digunakan untuk mengganti sistem lama. Saat ini, adalah umum bagi sebuah basis data untuk memiliki peralatan yang dapat memuat file yang ada ke dalam basis data baru. Peralatan tersebut biasanya membutuhkan spesifikasi dari file sumber dan basis data yang dituju, kemudian secara otomatis mengubah data ke dalam bentuk yang sesuai dengan basis data baru. 2.3.10 Uji Coba (Testing) Tahap uji coba merupakan proses pelaksanaan program aplikasi dengan tujuan untuk mendeteksi kesalahan. Sebelum dijalankan, aplikasi basis data yang baru selesai dikembangkan harus diuji dengan seksama.
15
Proses uji coba ini dilakukan dengan menggunakan strategi uji perencanaan secara hati-hati dan data-data yang nyata. 2.3.11 Pemeliharaan Operasional (Operational Maintenance) Pemeliharaan operasional merupakan kegiatan untuk memantau dan memelihara sistem yang telah diinstal. Kegiatan-kegiatan yang dilakukan dalam tahap ini yaitu : •
Memantau performa sistem
•
Memelihara dan meningkatkan level aplikasi basis data (jika dibutuhkan)
2.4 Metodologi Perancangan Basis Data Metodologi perancangan merupakan sebuah pendekatan terstruktur yang menggunakan prosedur, teknik, peralatan, serta dokumen pendukung untuk mendukung dan menyediakan fasilitas untuk proses perancangan (Connolly & Begg, 2002, p.418). Sebuah metodologi perancangan terdiri dari sejumlah fase, dimana masing-masing fase mengandung sejumlah tahap yang dapat menuntun perancang dalam menentukan teknik yang sesuai untuk setiap tahapan proyek. Metodologi perancangan juga dapat membantu perancang untuk menyusun rencana, mengatur, mengawasi, dan mengevaluasi pembangunan basis data. Dalam metodologi perancangan basis data, proses perancangan dibagi menjadi tiga tahap, yaitu perancangan konseptual, perancangan logikal, dan perancangan fisikal. Berikut ini adalah penjelasan dari setiap tahap tersebut. 2.4.1 Perancangan Basis Data Konseptual Perancangan basis data konseptual adalah proses pembentukan sebuah model informasi yang digunakan oleh sebuah perusahaan dan tidak terikat
16
dengan semua pertimbangan fisikal, yang antara lain meliputi target DBMS, program aplikasi, bahasa pemrograman, platform perangkat keras, atau masalah-masalah performa (Connolly & Begg, 2002, p.419). Tahap-tahap dalam perancangan basis data konseptual yaitu : 2.4.1.1 Membangun Model Data Konseptual Lokal Tahap ini bertujuan untuk membangun model data konseptual lokal suatu perusahaan untuk maksud tertentu. Tahap ini terbagi menjadi sembilan langkah, yaitu : a. Identifikasi tipe entity Langkah ini bertujuan untuk mengidentifikasi tipe entity utama yang dibutuhkan oleh perusahaan. b. Identifikasi tipe relasi Langkah ini bertujuan untuk mengidentifikasi relasi penting yang ada diantara tipe entity yang telah diidentifikasikan sebelumnya. c. Identifikasi dan asosiasi atribut dengan tipe entity atau relasi Langkah ini bertujuan untuk mengasosiasikan atribut dengan tipe entity atau tipe relasi yang tepat. d. Penentuan ruang lingkup atribut (attribute domain) Langkah ini bertujuan untuk menentukan ruang lingkup dari masing-masing atribut di dalam model data konseptual lokal. e. Penentuan atribut primary key dan candidate key Langkah ini bertujuan untuk menentukan candidate key untuk setiap tipe entity dan, apabila terdapat lebih dari satu candidate key, memilih salah satu candidate key untuk menjadi primary key.
17
f. Pertimbangan penggunaan konsep model enhanced Langkah ini bertujuan untuk mempertimbangkan penggunaan konsep model enhanced seperti spesialisasi/generalisasi, agregasi, dan komposisi. g. Pemeriksaan model terhadap redundansi Langkah ini bertujuan untuk memeriksa kemungkinan terjadinya redundansi di dalam model data. Adapun kegiatan yang dilakukan pada langkah ini adalah : •
Memeriksa kembali hubungan one to one (1 : 1) Pada saat mengidentifikasikan entity mungkin saja kita telah mengidentifikasi dua entity yang merepresentasikan obyek yang sama di perusahaan.
•
Menghilangkan hubungan yang redundan Sebuah hubungan dikatakan redundan apabila informasi yang sama dapat diakses melalui hubungan lain.
h. Validasi model konseptual lokal terhadap transaksi pengguna Langkah ini bertujuan untuk memastikan bahwa model konseptual lokal dapat mendukung transaksi yang dibutuhkan oleh perusahaan. i. Peninjauan kembali model data konseptual lokal dengan pengguna Langkah ini bertujuan untuk memastikan bahwa model tersebut merupakan gambaran tujuan yang sesungguhnya.
18
2.4.2 Perancangan Basis Data Logikal Perancangan basis data logikal adalah proses pembentukan sebuah model informasi yang digunakan di dalam perusahaan dan berdasarkan pada suatu model data spesifik, namun tidak terikat oleh sebuah DBMS khusus serta pertimbangan fisikal lainnya (Connolly & Begg, 2002, p.441). Tahap-tahap dalam perancangan basis data logikal yaitu : 2.4.2.1 Membangun dan Memvalidasi Model Data Logikal Lokal Tahap ini bertujuan untuk membangun sebuah model data logikal lokal dari sebuah model data konseptual lokal yang akan merepresentasikan tujuan khusus dari perusahaan, dan kemudian memvalidasi model ini untuk memastikan apakah model data ini telah terstruktur dengan benar serta dapat mendukung transaksi-transaksi yang dibutuhkan. Tahap ini terbagi menjadi enam langkah, yaitu : a. Menghilangkan fitur yang tidak sesuai dengan model relasional Langkah ini bertujuan untuk memperbaiki model data konseptual lokal yang masih mengandung fitur-fitur yang tidak sesuai dengan model relasional. Secara khusus, kegiatan-kegiatan yang dilakukan pada tahap ini adalah : •
Menghilangkan tipe relasi biner many to many (* : *)
•
Menghilangkan tipe relasi rekursif many to many (* : *)
•
Menghilangkan tipe relasi kompleks
•
Menghilangkan atribut multi valued
19
b. Membuat relasi untuk model data logikal lokal Langkah ini bertujuan untuk membuat relasi-relasi yang dapat merepresentasikan entity, hubungan, dan atribut yang telah diidentifikasi sebelumnya. Berikut ini adalah cara membuat relasi dari struktur-struktur yang mungkin disajikan di dalam model data. •
Menentukan tipe entity kuat Untuk semua entity kuat yang terdapat di dalam model data, dibentuk sebuah tabel yang mengandung semua atribut sederhana dari entity tersebut.
•
Menentukan tipe entity lemah Untuk semua entity lemah yang terdapat di dalam model data, dibentuk sebuah tabel yang mengandung semua atribut sederhana dari entity tersebut. Namun primary key entity lemah diperoleh dari entity kuat, sehingga primary key dari entity lemah belum dapat diidentifikasikan sampai semua hubungan dengan entity kuat telah selesai dipetakan.
•
Tipe relasi biner one to many (1 : *) Untuk setiap relasi biner one to many, entity pada ‘sisi satu’ akan dirancang sebagai parent entity dan entity pada ‘sisi banyak’ dirancang sebagai child entity.
•
Tipe relasi biner one to one (1 : 1) Membuat relasi untuk menggambarkan suatu hubungan one to one sedikit lebih rumit karena cardinality tidak dapat digunakan untuk membantu mengidentifikasi parent entity dan child entity.
20
Oleh karena itu digunakan beberapa pertimbangan berikut untuk membentuk relasi. - Mandatory participation di kedua sisi pada hubungan one to one, dimana kedua entity akan dikombinasikan ke dalam satu tabel, dan kemudian memilih salah satu primary key dari kedua entity yang asli sebagai primary key untuk tabel baru. - Mandatory participation di salah satu sisi pada hubungan one to one, dimana duplikat primary key dari parent entity akan ditempatkan pada tabel yang akan merepresentasikan child entity. - Optional participation di kedua sisi pada hubungan one to one, dimana penentuan parent entity dan child entity dapat berubah-ubah. •
Relasi rekursif one to one (1 : 1) Aturan untuk relasi rekursif one to one sama seperti aturan untuk relasi one to one yang telah dijelaskan diatas.
•
Tipe relasi Superclass/Subclass Untuk setiap relasi superclass/subclass, entity superclass akan didefinisikan sebagai parent entity dan entity subclass sebagai child entity.
•
Tipe relasi biner many to many (* : *) Untuk setiap relasi many to many, dibentuk sebuah tabel untuk menggambarkan hubungan-hubungan dan atribut-atribut yang menjadi bagian dari relasi tersebut. Duplikat primary key dari
21
entity-entity
yang
berpartisipasi
dalam
relasi
ini
akan
ditempatkan di dalam tabel baru sebagai foreign key. •
Tipe relasi kompleks Untuk setiap relasi kompleks, dibuat sebuah tabel untuk menggambarkan hubungan-hubungan dan atribut-atribut yang menjadi bagian dari relasi tersebut. Duplikat primary key dari entity-entity yang berpartisipasi di dalam relasi ini akan ditempatkan di dalam tabel baru sebagai foreign key.
•
Atribut Multi-Valued Untuk setiap atribut multi-valued di dalam sebuah entity, dibuat sebuah tabel baru untuk menggambarkan atribut multi-valued, termasuk primary key dari entity tersebut ke dalam tabel baru yang akan ditempatkan sebagai foreign key.
c. Validasi relasi dengan menggunakan teknik normalisasi Langkah ini bertujuan untuk memvalidasi relasi-relasi yang ada di dalam model data logikal lokal guna memastikan bahwa model data yang dihasilkan sudah hampir sesuai dengan yang diinginkan oleh perusahaan, konsisten, memiliki jumlah redundansi yang minimum, serta memiliki tingkat kestabilan yang maksimum. d. Validasi relasi terhadap transaksi pengguna Langkah ini bertujuan untuk memastikan bahwa relasi-relasi yang ada di dalam model data logikal lokal dapat mendukung transaksitransaksi yang dibutuhkan oleh perusahaan.
22
e. Penentuan batasan integritas Langkah ini bertujuan untuk menentukan batasan-batasan integritas agar dapat melindungi basis data dari ketidakkonsistenan. f. Peninjauan kembali model data logikal lokal dengan pengguna Langkah ini bertujuan untuk memastikan bahwa model data logikal lokal dan dokumen-dokumen pendukung yang menjelaskan model data tersebut merupakan gambaran tujuan yang sesungguhnya. 2.4.2.2 Membangun dan Memvalidasi Model Data Logikal Global Tahap ini bertujuan untuk menggabungkan model-model data logikal lokal ke dalam sebuah model data logikal global yang akan mewakili perusahaan. Tahap ini terbagi menjadi empat langkah, yaitu : a. Menggabungkan model data logikal lokal ke dalam model global Langkah ini bertujuan untuk menggabungkan semua model data logikal lokal individu ke dalam sebuah model data logikal global perusahaan. b. Validasi model data logikal global Langkah ini bertujuan untuk memvalidasikan tabel-tabel yang dibentuk dari model data logikal global dengan menggunakan teknik normalisasi, serta untuk memastikan bahwa model ini dapat mendukung transaksi-transaksi yang dibutuhkan. c. Memeriksa perkembangan di masa depan Langkah ini bertujuan untuk menentukan apakah terdapat perubahan penting yang mungkin terjadi di waktu mendatang dan
23
telah dapat diduga sebelumnya, serta untuk memperkirakan apakah model data logikal dapat mengakomodasi perubahan tersebut. d. Peninjauan kembali model data logikal global dengan pengguna Langkah ini bertujuan untuk memastikan bahwa model data logikal global tersebut merupakan gambaran tujuan yang sesungguhnya. 2.4.3 Perancangan Basis Data Fisikal Perancangan basis data fisikal adalah proses pendeskripsian hasil implementasi basis data pada media penyimpanan tambahan, dimana dalam deskripsi tersebut dijelaskan tentang relasi-relasi dasar, organisasi file, serta indeks-indeks yang digunakan untuk memperoleh akses data yang efisien, batasan-batasan integritas yang terasosiasi, dan tindakan-tindakan pengamanan (Connolly & Begg, 2002, p.478). Tahap-tahap dalam perancangan basis data fisikal yaitu : 2.4.3.1 Menerjemahkan Model Data Logikal Global Untuk Target DBMS Tahap ini bertujuan untuk menghasilkan skema relasional basis data dari model data logikal global yang dapat diimplementasikan ke dalam target DBMS. Tahap ini terbagi menjadi tiga langkah, yaitu : a. Merancang relasi dasar Langkah ini bertujuan untuk menentukan bagaimana cara merepresentasikan tabel-tabel yang telah diidentifikasi dalam model data logikal global pada target DBMS.
24
b. Merancang representasi data yang sudah diperoleh Langkah ini bertujuan untuk menentukan bagaimana cara merepresentasikan setiap data yang sudah diperoleh dan telah tersaji di dalam model data logikal global pada target DBMS. c. Merancang batasan perusahaan Langkah ini bertujuan untuk merancang batasan-batasan perusahaan untuk target DBMS. 2.4.3.2 Merancang Representasi Fisikal Tahap ini bertujuan untuk menentukan organisasi-organisasi file yang optimal untuk menyimpan relasi-relasi dasar dan indeks-indeks yang dibutuhkan guna memperoleh performa yang diharapkan. Tahap ini terbagi menjadi empat langkah, yaitu : a. Analisis transaksi Langkah ini bertujuan untuk memahami fungsionalitas dari setiap transaksi yang akan dijalankan di basis data, serta menganalisis transaksi-transaksi penting. b. Pemilihan organisasi file Langkah ini bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. c. Penentuan indeks Langkah ini bertujuan untuk menentukan apakah penambahan indeks dapat meningkatkan performa sistem.
25
d. Memprediksi kebutuhan kapasitas disk Langkah ini bertujuan untuk memperkirakan jumlah ruang disk yang dibutuhkan oleh basis data. 2.4.3.3 Merancang Keinginan Pengguna Langkah ini bertujuan untuk merancang keinginan pengguna yang telah diidentifikasikan sejak tahap pengumpulan dan analisis kebutuhan pada siklus hidup aplikasi basis data relasional. 2.4.3.4 Merancang Mekanisme Keamanan Langkah ini bertujuan untuk merancang mekanisme keamanan bagi basis data yang telah dispesifikasikan oleh pengguna. 2.4.3.5 Mempertimbangkan Pengenalan Tentang Redundansi Terkontrol Langkah ini bertujuan untuk menentukan apakah pengenalan redundansi di dalam sebuah cara yang terkontrol dengan mengurangi aturan-aturan normalisasi akan dapat meningkatkan performa sistem. 2.4.3.6 Memantau Sistem Operasional Langkah ini bertujuan untuk memantau sistem operasional dan menunjukkan performa sistem guna memperbaiki keputusan-keputusan rancangan yang tidak sesuai, atau merefleksikan perubahan kebutuhan. 2.5 Teori Penjualan Kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa, baik secara kredit maupun tunai (Mulyadi, 2002, p.202). Dalam transaksi kredit, jika pesanan dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, maka untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Kegiatan penjualan secara kredit ini ditangani oleh perusahaan
26
melalui sistem penjualan kredit. Sedangkan dalam transaksi penjualan tunai, barang atau jasa baru akan diserahkan oleh perusahaan kepada pembeli jika perusahaan telah menerima kas dari pembeli. Kegiatan penjualan secara tunai ini ditangani oleh perusahaan melalui sistem penjualan tunai. Dalam transaksi penjualan, tidak semua penjualan berhasil mendatangkan pendapatan (revenue) bagi perusahaan. Adakalanya pembeli mengembalikan barang yang telah dibelinya kepada perusahaan. Transaksi pengembalian barang oleh pembeli ini ditangani perusahaan melalui sistem retur penjualan. 2.5.1 Sistem Penjualan Kredit Penjualan kredit dilakukan oleh perusahaan dengan cara mengirimkan barang sesuai dengan pesanan yang diterima dari pembeli, dan untuk jangka waktu tertentu perusahaan mempunyai tagihan kepada pembeli tersebut. Untuk menghindari tidak tertagihnya piutang, setiap penjualan kredit yang pertama kepada seorang pembeli selalu didahului dengan analisis mengenai dapat atau tidaknya pembeli tersebut diberikan kredit. Menurut Mulyadi (2002, p.211), fungsi-fungsi yang tekait dalam sistem penjualan kredit yaitu : 2.5.1.1 Fungsi Penjualan Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk menerima surat pesanan dari pembeli, mengedit pesanan dari pelanggan untuk menambahkan informasi yang belum ada pada surat pesanan tersebut, meminta otorisasi kredit, menentukan tanggal pengiriman dan dari gudang mana barang akan dikirim, serta mengisi surat pesanan pengiriman. Fungsi ini juga bertanggung jawab untuk
27
membuat back order pada saat diketahui tidak tersedianya persediaan untuk memenuhi pesanan dari pelanggan. 2.5.1.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. Jika penolakan pemberian kredit seringkali terjadi, maka pengecekan status kredit perlu dilakukan sebelum fungsi penjualan mengisi surat pesanan penjualan. Untuk mempercepat pelayanan bagi pelanggan, surat pesanan pengiriman dikirimkan 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 akan memberitahu fungsi pengiriman untuk membatalkan pengiriman barang kepada pihak pembeli. 2.5.1.3 Fungsi Gudang Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk menyimpan barang yang dipesan oleh pelanggan, serta menyerahkan barang ke fungsi pengiriman. 2.5.1.4 Fungsi Pengiriman Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk menyerahkan barang atas dasar surat pesanan pengiriman yang diterimanya dari fungsi penjualan. Fungsi ini bertanggung jawab untuk
28
menjamin bahwa tidak ada barang yang keluar dari perusahaan tanpa ada otorisasi dari yang berwenang. Otorisasi ini dapat berupa surat pesanan 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. 2.5.1.5 Fungsi Penagihan Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk membuat dan mengirimkan faktur penjualan kepada pelanggan, serta menyediakan salinan faktur bagi kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi. Fungsi ini berada di bagian penagihan. 2.5.1.6 Fungsi Akuntansi Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk mencatat piutang yang muncul dari transaksi penjualan kredit, membuat dan mengirimkan pernyataan piutang kepada para debitur, serta membuat laporan penjualan. Disamping itu, fungsi ini juga bertanggung jawab untuk mencatat harga pokok persediaan yang dijual ke dalam kartu persediaan. Dalam struktur organisasi, fungsi ini berada di tangan bagian piutang (sebagai penyelenggara kartu piutang), bagian jurnal (penyelenggara jurnal penjualan dan pembuatan laporan penjualan), dan bagian persediaan (sebagai penyelenggara kartu persediaan).
29
Menurut Mulyadi (2002, p.219), ada tujuh jaringan prosedur yang membentuk sistem penjualan kredit. Ketujuh prosedur tersebut yaitu : a. Prosedur order penjualan, dimana fungsi penjualan menerima pesanan dari pembeli dan menambahkan informasi penting pada surat pemesanan dari pembeli. Kemudian fungsi penjualan akan membuat surat pengiriman pesanan dan mengirimkannya kepada berbagai fungsi yang lain. b. Prosedur persetujuan kredit, dimana fungsi penjualan meminta persetujuan kredit kepada pembeli tertentu dari fungsi kredit. c. Prosedur penagihan, dimana fungsi penagihan membuat faktur penjualan dan mengirimkannya kepada pembeli. d. Prosedur pencatatan piutang, dimana fungsi akuntansi mencatat tembusan faktur penjualan ke dalam kartu piutang. e. Prosedur distribusi penjualan, dimana fungsi akuntansi mendistribusikan data penjualan menurut informasi yang dibutuhkan oleh manajemen. f. Prosedur pencatatan harga pokok penjualan, dimana fungsi akuntansi mencatat total harga pokok produk yang dijual dalam periode akuntansi tertentu secara periodik. 2.5.2 Sistem Penjualan Tunai Penjualan tunai dilakukan oleh perusahaan dengan cara mewajibkan pembeli melakukan pembayaran harga barang terlebih dahulu sebelum barang diserahkan ke pembeli oleh perusahaan. Setelah uang diterima oleh perusahaan, barang kemudian diserahkan kepada pihak pembeli dan selanjutnya transaksi penjualan tunai dicatat oleh
30
perusahaan. Berdasarkan sistem pengendalian internal yang baik, sistem penerimaan kas dari penjualan tunai mengharuskan : •
Penerimaan kas dalam bentuk tunai harus segera disetor ke bank dalam jumlah penuh dengan cara melibatkan pihak lain selain kasir untuk melakukan pemeriksaan internal.
•
Penerimaan kas dari penjualan tunai yang dilakukan melalui transaksi kartu kredit melibatkan bank penerbit kartu kredit dalam pencatatan transaksi penerimaan kas.
Sistem penerimaan kas dari penjualan tunai dibagi menjadi tiga prosedur, yaitu : •
Prosedur penerimaan kas dari Over The Counter Sales
•
Prosedur penerimaan kas dari COD Sales (Cash On Delivery Sales)
•
Prosedur penerimaan kas dari Credit Card Sales
