BAB 2 LANDASAN TEORI 2.1 Pengertian Basis Data Ada beberapa

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