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 batasan-

batasan sistem dan bagaimana sistem tersebut akan berinteraksi dengan bagian-

bagian 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 transaksi-

transaksi 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