bab 2 landasan teori 2.1 teori – teori dasar 2.1.1...
TRANSCRIPT
9
BAB 2
LANDASAN TEORI
2.1 Teori – teori Dasar
2.1.1 Pengertian Data
Menurut Kadir (2000, p7), data adalah fakta mengenai suatu objek
atau orang. Data dinyatakan dengan nilai (angka, deretan karakter, atau
simbol). Hirarki data menurut Kadir (2000, p8-9) secara tradisional data
diorganisasikan ke dalam suatu hirarki yang terdiri atas elemen data,
rekaman (record) dan berkas (file).
• Elemen Data
Elemen data adalah suatu data terkecil yang tidak dapat di pecah lagi
jadi unit lain yang bermakna. Istilah lain untuk elemen data adalah
medan (field), kolom, item, atribut.
• Rekaman / Record
Rekaman adalah gabungan sejumlah data yang saling berkaitan. Dalam
sistem basis data relasional rekaman biasa disebut dengan baris.
• Berkas (file)
10
Berkas adalah himpunan seluruh rekaman yang bertipe sama
membentuk sebuah berkas. Berkas dapat dikatakan sebagai kumpulan
data yang berkaitan dengan suatu subjek. Dalam sistem basis data
relasional, berkas mewakili komponen yang disebut table atau relasi.
2.1.2 Sistem Basis Data
Menurut Connoly dan Begg (2002, p14), basis data adalah
kumpulan data yang berelasi secara logika, di desain untuk mendapatkan
informasi yang dibutuhkan sebuah organisasi. Di dalam basis data, semua
data diintegrasikan untuk menghindari duplikasi data. Basis data dapat
digunakan oleh banyak departemen dan pemakai. Basis data tidak hanya
memegang data operasional organisasi, tetapi juga penjelasan mengenai
data tersebut.
Menurut Ramakrishnan dan Gehrke (2003, p4), basis data adalah
suatu koleksi data, yang secara khas menggambarkan aktivitas organisasi
yang satu dengan organisasi yang terkait.
Menurut Elmasri dan Navathe (2000, p4), sebuah basis data adalah
kumpulan dari relasi-relasi data sehingga dapat mengetahui fakta yang
dapat direcord dan memiliki arti lengkap.
Menurut Post, Gerald (2005, p2), sistem basis data merupakan
kumpulan data yang disimpan dalam format yang standard dan dirancang
untuk dibagikan oleh berbagai pemakai.
11
2.1.2.1 Keuntungan Menggunakan Basis Data
Keuntungan yang dapat diperoleh dengan menggunakan
basis data adalah:
a. Basis data dapat mengurangi redudansi data.
b. Basis data dapat meningkatkan integritas data.
c. Basis data dapat menjaga independensi data
(ketidaktergantungan data).
d. Basis data dapat meningkatkan keamanan data.
e. Basis data dapat menjaga konsistensi data.
f. Basis data dapat menyediakan manipulasi data yang baik.
g. Dengan menggunakan basis data, maka data lebih mudah
untuk diakses dan digunakan.
h. Basis data dapat mengakibatkan lebih banyak informasi yang
di dapat dari data yang sama.
i. Penggunaan basis data dapat memungkinkan datanya dapat di
share (digunakan bersama).
j. Dengan menggunakan basis data maka dapat mempermudah
pengoperasian terhadap data.
k. Basis data dapat meningkatkan layanan backup dan recovery.
l. Basis data dapat meningkatkan produktivitas.
m. Basis data dapat mempermudah proses pemeliharaan
(maintenance) melalui independensi data, sehingga biaya yang
dikeluarkan relatif lebih murah.
12
n. Penggunaan basis data dapat meningkatkan proses
accessibility dan responsiveness data.
o. Basis data dapat meningkatkan concurrency.
p. Dengan menggunakan basis data, maka kinerja perusahaan
akan menjadi lebih efektif dan efisien.
2.1.2.2 Kekurangan Menggunakan Basis Data
Sedangkan yang menjadi kekurangan dari penggunaan
basis data (database) adalah:
a. Data menjadi lebih kompleks.
b. Ukuran atau size yang harus disediakan untuk membuat suatu
basis data lebih besar daripada sekedar menyimpan record.
c. Harus menyediakan biaya yang lebih untuk menambahkan
perangkat keras (hardware).
d. Biaya awal yang harus disediakan relatif lebih besar untuk
suatu DBMS.
2.1.3 Pengertian Sistem Basis Data
Date (2002, p5), mengemukakan bahwa sistem basis data pada
dasarnya merupakan sistem penyimpanan record yang terkomputerisasi.
Dengan kata lain, sistem basis data merupakan sistem terkomputerisasi
yang bertujuan untuk menyimpan informasi dan memungkinkan pemakai
13
untuk mengambil kembali dan memperbaharui informasi tersebut sesuai
dengan keinginan dan permintaan.
Sistem basis data mempunyai empat komponen utama, yaitu:
hardware (perangkat keras), software (perangkat lunak), data dan user.
Hardware (perangkat keras) pada sistem basis data terdiri dari secondary
storage device (perangkat penyimpanan sekunder), I/O device (perangkat
input output), database machines (mesin basis data). Software (perangkat
lunak) secara umum berfungsi membantu pengguna basis data untuk
melakukan operasi terhadap data.
2.1.4 Database Management Sistem (DBMS)
Menurut Connoly dan Begg (2002, p16), Database Management
System (DBMS) merupakan suatu piranti lunak untuk membuat pemakai
dapat mendefinisikan, menciptakan, mengatur, dan mengontrol akses ke
dalam basis data. DBMS menyediakan beberapa fasilitas sebagai berikut:
a. Data Definition Language (DDL): memungkinkan pemakai untuk
membuat spesifikasi tipe data, mendefinisikan basis data, struktur data
dan constraint data disimpan ke dalam basis data.
b. Data Manipulation Language (DML): memperbolehkan pemakai untuk
memasukkan, memperbaharui, menghapus, dan mengirim atau
mengambil data dari basis data.
c. DBMS menyediakan controlled access ke basis data, misalnya:
14
- A security system, mencegah adanya akses ke basis data oleh
pengguna yang tidak memiliki otoritas.
- An integrity system, memelihara konsistensi data yang disimpan
dalam basis data.
- A concurrency control system, memungkinkan akses secara
bersama–sama pada basis data.
- A recovery control system, mengembalikan basis data ke kondisi
sebelumnya dengan konsisten.
- An user – accessible catalog, berisikan deskripsi dari data di dalam
basis data.
Menurut Kadir (2000, p17), DBMS diartikan sebagai suatu program
komputer yang digunakan untuk memasukkan, mengubah, menghapus,
memanipulasi, dan memperoleh data dan informasi dengan praktis dan
efisien.
DBMS adalah piranti lunak yang dirancang untuk membantu dan
memelihara dan memanfaatkan data dalam jumlah besar, dan kebutuhan
untuk sistem maupun pemakaiannya yang berkembang dengan cepat
(Ramakrishnan dan Gehrke, 2003, p4).
DBMS adalah piranti lunak yang mendefinisikan sebuah basis data,
menyimpan data, mendukung bahasa query, membuat laporan dan
menciptakan layer masukan data (Gerald V.Post, 2005, p2).
15
2.1.4.1 Komponen Database Management Sistem (DBMS)
Menurut Connoly dan Begg (2002, p18), ada lima
komponen utama dari DBMS, yaitu hardware, software, data,
procedure, dan SDM.
1. Hardware (perangkat keras)
Suatu DBMS dan aplikasinya menggunakan hardware untuk
menjalankan aplikasinya. Hardware dapat disusun dari suatu
komputer tunggal, suatu mainframe tunggal, suatu jaringan
komputer.
2. Software (perangkat lunak)
Komponen piranti lunak meliputi software DBMS dan
program aplikasi beserta sistem operasi (OS), termasuk piranti
lunak tentang jaringan, bila DBMS digunakan dalam jaringan
seperti LAN.
3. Data
Data merupakan komponen terpenting dalam DBMS
khususnya sudut pandang end user mengenai data. Data pada
sebuah sistem basis data baik single user sistem maupun multi
user sistem harus terintegrasi dan dapat digunakan secara
bersama.
16
4. Prosedur
Prosedur berupa instruksi dan aturan–aturan yang membuat
rancangan dan menggunakan basis data. Penggunaan sistem
dan staff yang mengatur kebutuhan basis data
didokumentasikan dalam prosedur yang berupa petunjuk
penggunaan sistem atau petunjuk menjalankan sistem.
Instruksi tersebut misalnya bagaimana untuk:
a. Log on ke DBMS
b. Menggunakan sebagian fasilitas DBMS atau program
aplikasi
c. Start dan stop DBMS
d. Membuat salinan basis data
e. Menangani kesalahan pada hardware dan software
f. Mengubah struktur suatu tabel dan meningkatkan tampilan
5. Manusia
Komponen terakhir adalah manusia yang terlibat langsung
dengan sistem tersebut. Manusia dibedakan menjadi tiga,
yaitu:
a. Application Programmers, bertanggung jawab untuk
membuat aplikasi basis data dengan menggunakan bahasa
17
pemograman yang ada, seperti: C++, Java dan lain
sebagainya.
b. End User, siapapun yang berinteraksi dengan sistem
secara online melalui workstation / terminal.
c. DA (Data Administrator), seseorang yang berwenang
untuk membuat keputusan strategis dan kebijakan
mengenai data yang ada, DBA (Database Administrator),
menyediakan dukungan teknis untuk
mengimplementasikan keputusan tersebut, dan
bertanggung jawab atas keseluruhan kontrol sistem pada
tingkat teknis.
2.1.4.2 Fungsi DBMS
Menurut Connoly dan Begg (2002, p48), ada beberapa
fungsi dari DBMS adalah sebagai berikut:
1. Data Storage, retrieval, and update
Sebuah DBMS harus melengkapi / menyediakan untuk
pengguna dengan kemampuan penyimpanan, penelusuran
kembali, dan mengubah data dalam basis data.
2. A user-accessible catalog
Sebuah DBMS harus menyediakan catalog yang
mendeskripsikan lokasi penyimpanan data dalam basis data.
18
3. Transaction Support
DBMS harus menyediakan mekanisme yang menjamin semua
kegiatan update yang berhubungan dengan transaksi.
4. Concurrency control services
DBMS harus menyediakan sebuah mekanisme untuk
menjamin bahwa basis data ter-update dengan benar ketika
beberapa pengguna meng-update dengan benar dan pada saat
beberapa pengguna meng-update basis data pada waktu yang
bersamaan.
5. Recovery Service
DBMS harus menyediakan sebuah mekanisme untuk
memperbaiki basis data yang rusak karena suatu kejadian.
6. Authorization Service
DBMS harus menyediakan sebuah mekanisme untuk
menjamin bahwa hanya pengguna yang diberi otoritas yang
dapat mengakses basis data.
7. Support for Data Communication
DBMS harus mampu berintegrasi dengan software
komunikasi.
19
8. Integrity Service
DBMS harus menyediakan sebuah cara untuk menjamin
bahwa data dalam basis data, keduanya mengikuti aturan-
aturan yang tepat.
9. Service to promote data independence
DBMS harus meliputi fasilitas-fasilitas yang mendukung
program-program independensi dari struktur basis data aktual.
10. Utility Service
DBMS seharusnya menyediakan sekumpulan utility service
agar basis data dapat diadministrasi secara efektif.
2.1.4.3 Keuntungan dan Kerugian DBMS
DBMS memungkinkan untuk menciptakan basis data
dalam penyimpanan akses langsung ke komputer, memelihara
isinya dan menyediakan isi tersebut bagi pemakai tanpa
pemograman khusus yang mahal. Akan tetapi, sebelum
memutuskan untuk menggunakan DBMS atau tidak, keuntungan
dan kerugiannya harus dipertimbangkan.
Menurut McLeod (2004, p152), keuntungan DBMS adalah
sebagai berikut:
20
- Mengurangi pengulangan data
Dalam suatu DBMS tidak ada duplikasi data.
- Independence Data
Spesifikasi data disimpan dalam skema di setiap program
aplikasi sehingga perubahan dapat dibuat pada struktur data
tanpa mempengaruhi data yang lain.
- Mengintegrasi data dari beberapa file
Adanya gabungan data yang terkumpul dalam suatu file.
- Pengambilan data dan informasinya cepat
Hubungan logis dan DML serta query language
memungkinkan pengguna untuk mengambil data dalam
hitungan detik atau menit.
- Meningkatkan keamanan
Baik DBMS mainframe maupun komputer micro dapat
menyertakan beberapa lapisan keamanan seperti kata sandi
(password), direktori pemakai, dan bahasa sandi (encryption).
Data yang disimpan dan dikelola dalam DBMS juga lebih
aman daripada data lain yang ada dalam perusahaan.
21
Sedangkan kerugian DBMS adalah sebagai berikut:
- Piranti lunak yang mahal
DBMS mainframe masih sangat mahal.
- Konfigurasi perangkat keras yang besar
DBMS memerlukan kapasitas penyimpanan primer dan
sekunder yang lebih besar.
- Mempekerjakan dan mempertahankan Staff DBA (Database
Administrator)
DBMS memerlukan pengetahuan yang khusus agar dapat
memanfaatkan kemampuannya secara penuh.
2.1.5 Entity Relationship Modelling
Menurut Connoly dan Begg (2002, p330), salah satu aspek yang
sulit dalam perancangan basis data adalah kenyataan bahwa perancang,
programmer, dan pemakai akhir cenderung melihat data dalam cara yang
berbeda. Untuk memastikan pemahaman secara ilmiah dari data dan
bagaimana data digunakan oleh perusahaan dibutuhkan sebuah bentuk
komunikasi yang non teknis dan bebas dari kebingungan.
22
2.1.5.1 Entity Type
Entity Type adalah kumpulan dari objek-objek dengan
sifat atau properti yang sama, yang didefinisikan oleh perusahaan
yang mempunyai eksistensi yang independen. Keberadaannya
dapat berupa fisik atau abstrak.
Konsep dasar dari bentuk Entity Relationship adalah tipe
entitas. Sebuah tipe entitas memiliki keberadaan yang bebas dan
bisa menjadi obyek dengan keberadaan fisik atau menjadi obyek
dengan keberadaan konseptual. Ini berarti perancang yang
berbeda mungkin mengidentifikasikan entitas yang berbeda.
Entity Occurrence adalah obyek dan tipe entitas yang
dapat di identifikasikan secara unik.
2.1.5.2 Relationship Type
Setiap relasi diberi nama sesuai dengan fungsinya.
Relationship Occurrence adalah suatu gabungan yang dapat
diidentifikasikan secara unik, yang meliputi suatu kejadian dari
setiap tipe entitas yang berpartisipasi.
Derajat dari relasi adalah jumlah dari partisipasi tipe
entitas dalam sebuah tipe relasi tertentu. Entitas yang berkaitan
dalam sebuah tipe relasi terkenal sebagai participant dalam
relationship dan jumlah participant dalam relationship disebut
23
sebagai derajat dari relationship. Oleh karena itu, derajat dari
sebuah relationship berderajat dua disebut binary, sedangkan
relationship berderajat tiga disebut sebagai ternary, dan
seterusnya.
2.1.5.3 Attribute
Attribute adalah sifat dari sebuah entitas atau sebuah
relationship type. Attribute menyimpan nilai dari setiap entity
occurrence dan mewakili bagian utama dari data yang disimpan
dalam basis data.
Domain Attribute adalah satuan nilai-nilai untuk satu atau
beberapa atribut. Setiap atribut yang dihubungkan dengan
sejumlah nilai disebut domain. Domain mendefinisikan nilai-nilai
yang dimiliki sebuah atribut dan sama dengan konsep domain
pada model relasional.
Simple Attribute adalah suatu atribut yang terdiri atas
komponen tunggal dengan keberadaan yang tidak terikat. Atribut
ini tidak dapat lagi menjadi komponen yang lebih kecil.
Composite Attribute adalah atribut yang terdiri atas banyak
komponen, tiap-tiap komponen dengan keberadaan yang tidak
terikat atribut tertentu dapat dibagi lagi menjadi komponen yang
lebih kecil dengan keberadaan masing-masing yang tidak terikat.
24
Single Attribute adalah atribut yang menampung nilai
tunggal untuk tiap-tiap kejadian dari suatu tipe entitas. Sebagian
besar atribut adalah bernilai tunggal.
Multivated Attribute adalah atribut yang menampung
banyak nilai untuk setiap kejadian dari suatu tipe entitas.
Derived Attribute adalah atribut yang menggantikan
sebuah nilai yang diturunkan dari nilai sebuah atribut yang
berhubungan, tidak perlu pada jenis entitas yang sama.
2.1.5.4 Key
Candidate key adalah kunci yang secara unik mengenali
setiap kejadian di dalam tipe entitas. Sebuah candidate key tidak
boleh NULL. Sebuah entitas mungkin punya lebih dari satu
candidate key.
Primary key adalah candidate key yang dipilih sebagai
kunci primer untuk mengenali secara unik setiap occurrence dari
sebuah tipe entitas. Pemilihan Primary key untuk sebuah entitas
adalah berdasarkan pada pertimbangan panjang atribut, jumlah
minimal dari kebutuhan atribut, dan memenuhi syarat unik.
Candidate key yang tidak dipilih menjadi Primary key disebut
sebagai alternate key.
25
Composite key adalah candidate key yang terdiri dari dua
atribut atau lebih.
Foreign key adalah atribut dari suatu relasi yang cocok
pada candidate key dari beberapa relasi.
2.1.5.5 Structural Constraints
Tipe utama dari batasan hubungan di dalam relationship
disebut multiplicity. Multiplicity adalah jumlah kemungkinan
kejadian dari sebuah entitas yang mungkin berhubungan ke
sebuah kejadian tunggal dari sebuah entitas yang tergantung
melalui sebuah hubungan khusus.
Hubungan binary secara umum dibedakan menjadi:
- Derajat hubungan one to one ( 1 : 1 )
Derajat hubungan antara entitas 1 : 1 terjadi bila anggota suatu
entitas hanya boleh berpasangan dengan satu anggota dari
entitas yang lain. Sebaliknya angota dari entitas yang lain
hanya boleh berpasangan dengan satu anggota dari entitas
tersebut.
- Derajat hubungan one to many ( 1 : * )
Derajat hubungan ini terjadi apabila tiap anggota suatu entitas
boleh berpasangan dengan lebih dari satu anggota baru dari
26
entitas yang lain. Sebaliknya, tiap anggota entitas yang lain
hanya boleh berpasangan dengan satu anggota dari entitas
tersebut.
- Derajat hubungan many to many ( *: * )
Derajat hubungan antar entitas ini terjadi bila tiap anggota
suatu entitas boleh berpasangan dengan lebih dari satu
anggota dari entitas lain. Sebaliknya, tiap anggota dari entitas
lain juga boleh berpasangan dengan lebih dari satu anggota
dari entitas tersebut.
2.1.6 Normalisasi
Menurut Connoly dan Begg (2002, p376), normalisasi adalah suatu
teknik untuk menghasilkan seperangkat relasi untuk properti yang
diinginkan, dengan data yang diberikan oleh suatu perusahaan. Tujuan
utama dari suatu normalisasi adalah untuk mengurangi terjadinya data
ganda dan mengurangi masalah yang terjadi pada satu relasi atau lebih
yang dikenal dengan anomaly.
Anomaly adalah suatu masalah yang timbul seperti: data ganda, data
hilang, tempat pemborosan memori, dan data yang tidak konsisten akibat
proses penghapusan data, pembaruan data, pemasukan data dan
penggantian data (Connoly dan Begg (2002, p376)).
27
Menurut Connoly dan Begg (2002, p386), proses normalisasi
meliputi:
1. First Normal Form (1NF) adalah suatu relasi yang merupakan
perpotongan dari setiap baris dan kolom yang terdiri dari satu dan
hanya satu nilai. Untuk mentransformasi suatu unnormalized table ke
dalam bentuk normal pertama yang dilakukan dengan cara
mengidentifikasikan dan menghilangkan repeating group (group yang
berulang) yang terdapat dalam table.
2. Second Normal Form (2NF) adalah suatu relasi dalam bentuk normal
pertama (1NF) dan setiap atribut non-Primary-key yang bergantung
secara fungsional (fully functional dependency) terhadap Primary key.
3. Third Normal Form (3NF) adalah suatu relasi dalam bentuk normal
pertama (1NF) dan kedua (2NF) yang didalamnya tidak terdapat non-
Primary-key atribut yang bergantung secara transitif (transitive
dependency) terhadap Primary key.
Transitive dependencies terjadi bila kondisi A dimana A, B dan C
merupakan atribut dari suatu relasi jika A → B dan B → C, maka C
bergantung secara transitif terhadap A melalui B (asalkan A tidak
bergantung secara fungsional terhadap B atau C).
4. Bentuk Normal Boyce Codd Normal Form (BCNF). Pertama kali
diperkenalkan oleh R. Boyce dan E.F Codd. Bentuk normal BCNF
merupakan perbaikan dari bentuk normal yang ketiga, tapi tidak
28
menutup kemungkinan bahwa bentuk normal ketiga masih memiliki
Anomaly, sehingga perlu untuk di normalisasi lagi. Suatu relasi yang
memenuhi BCNF selalu memenuhi 3NF, tetapi belum tentu bentuk
normal 3NF memenuhi bentuk normal BCNF.
5. Fourth Normal Form (4NF) adalah suatu relasi dalam Boyce Codd
Normal Form (BCNF) dan tidak mengandung ketergantungan multi-
valued non trivial. Bentuk normal keempat merupakan bentuk yang
lebih kuat dari BCNF dimana 4NF mencegah relasi dari non trivial
multi-valued dependency dan data redundancy. Normalisasi dari BCNF
ke 4NF meliputi pemindahan multi-valued dependency dari relasi
dengan menempatkan atribut dalam sebuah relasi baru bersama dengan
determinan. Multi-valued dependency menggambarkan ketergantungan
antara atribut – atribut dalam suatu relasi.
2.1.7 Database Application Life Cycle
Menurut Connoly dan Begg (2002, p272), Database Application
Life Cycle merupakan komponen yang terpenting dalam sistem basis data
karena aplikasi dari database application life cycle berkaitan dengan sistem
informasi yang ada. Langkah – langkah dari Database Application Life
Cycle dapat dilihat pada gambar 2.1:
29
Gambar 2.1 Database Application Life Cycle
(Sumber : Connolly, 2005, p273)
30
1. Perancangan Basis Data (Database Planning)
Menurut Connoly dan Begg (2002, p273), merencanakan
bagaimana langkah–langkah dari life cycle dapat diterapkan dalam
sistem basis data secara efektif dan efisien. Perencanaan basis data
(Database Planning) harus terintegrasi dengan keseluruhan strategi
sistem informasi dari organisasi atau perusahaan yang bersangkutan.
Ada 3 masalah pokok dalam merumuskan suatu strategi sistem
informasi, antara lain:
- Identifikasikan rencana dan tujuan dengan penentuan sistem
informasi yang diperlukan.
- Evaluasi dari sistem informasi sekarang untuk menentukan
kelemahan dan kekuatan yang ada.
- Penentuan tentang peluang IT yang mungkin menghasilkan
keuntungan yang kompetitif.
Perencanaan basis data (Database Planning) meliputi pengembangan
standar, bagaimana data akan dikumpulkan, bagaimana rancangan dan
implementasi dapat diproses. Dalam merancang suatu standar yang baik
harus menyediakan suatu basis data untuk staff pelatihan dan mengukur
pengendalian mutu (quality), dan dapat memastikan bahwa pekerjaan
yang ada menyesuaikan diri pada suatu pola teladan, tanpa tergantung
dengan ketrampilan dan pengalaman staff.
31
2. Definisi Sistem (System Definition)
Menurut Connoly dan Begg (2002, p274), menentukan ruang
lingkup dari aplikasi basis data yang akan dibuat termasuk user dan
tempat dimana aplikasi basis data tersebut diterapkan. Sebelum
mencoba untuk merancang suatu aplikasi basis data, hal pertama yang
harus diperhatikan adalah mengidentifikasikan batasan–batasan sistem
yang ada dan bagaimana sistem tersebut dapat menghubungkan dengan
bagian lain yang terdapat dalam sistem informasi perusahaan.
Penentuan batasan–batasan sistem tidak hanya area aplikasi dan para
pemakai yang sekarang, tetapi juga aplikasi dan para pemakai masa
depan.
Suatu aplikasi basis data mungkin punya satu atau lebih user
views, mengidentifikasikan user views adalah suatu aspek yang penting
dalam mengembangkan aplikasi basis data yang relatif kompleks
karena user views dapat membuat basis data tersebut dipecah kedalam
bagian yang dapat dikendalikan.
User Views
User views menggambarkan apa yang diperlukan suatu aplikasi
basis data dalam kaitan dengan data yang disimpan dan transaksi untuk
dilakukan atas data (dengan kata lain, apa yang user akan lakukan atas
data tersebut). Kebutuhan user views mungkin akan berbeda dengan
view yang bersangkutan dengan view yang lain.
32
3. Mengumpulkan dan Menganalisa Kebutuhan dari User dan Area
Aplikasi (Requirement Collection and Analysis)
Menurut Connoly dan Begg (2002, p276), cara mengumpulkan
dan menganalisis kebutuhan user melibatkan analisis dan kumpulan
informasi tentang bagian dari perusahaan yang akan dibuat basis data.
Ada banyak teknik untuk mengumpulkan informasi, salah satunya
adalah teknik fact finding. Informasinya mencakup:
• Detail bagaimana data dapat digunakan atau dihasilkan.
• Kebutuhan tambahan lainnya untuk aplikasi basis data baru.
Informasi ini kemudian akan di analisis untuk
mengidentifikasikan kebutuhan yang mencakup dalam aplikasi basis
data baru. Kebutuhan ini diuraikan dalam dokumen secara bersama
dikenal sebagai spesifikasi kebutuhan untuk aplikasi basis data baru.
Analisa dan koleksi kebutuhan adalah suatu langkah persiapan
untuk merancang suatu basis data. Jumlah data yang dikumpulkan
tergantung pada sifat alami dari masalah dan kebijakan perusahaan.
Mengidentifikasikan kemampuan yang diperlukan untuk suatu aplikasi
basis data adalah suatu aktifitas yang penting, karena sistem dengan
kemampuan yang tidak sempurna atau tidak cukup akan mengganggu
user, yang memungkinkan sistem tersebut tidak digunakan lagi atau
ditolak. Bagaimanapun, kemampuan sistem yang berlebihan dapat juga
33
menjadi masalah misalnya suatu sistem yang terlalu rumit dapat
membuat sukar dalam penerapan, pemeliharaan, menggunakan atau
belajar menggunakan sistem tersebut.
4. Perancangan Basis Data (Database Design)
Menurut Connoly dan Begg (2002, p279), perancangan basis data
merupakan proses menciptakan desain untuk basis data yang akan
mendukung operasi dan tujuan perusahaan. Proses perancangan basis
data dibagi menjadi 3 tahap utama, yaitu:
A. Conceptual Database Design
Langkah awal dalam conceptual database design ini adalah
dengan membuat model data secara konseptual dari perusahaan
yang bersangkutan. Data tersebut merupakan informasi mengenai
perusahaan. Dalam menentukan model data secara konseptual data
yang tidak termasuk dalam sasaran DBMS, program aplikasi,
bahasa pemrograman, dan masalah dalam pembuatan basis data.
Langkah–langkahnya adalah:
Langkah 1: Membangun model data konseptual lokal untuk setiap
view
1.1 Mengidentifikasikan tipe entitas
34
Tujuan: mengidentifikasikan tipe entitas utama yang dibutuhkan
oleh view.
Entitas: kelompok obyek yang memiliki properti yang sama,
dan mempunyai keberadaan yang tidak tergantung. Entitas dapat
berupa:
- Obyek fisik seperti orang, tempat atau konsep
- Obyek konseptual / abstrak seperti kejadian
Entitas biasanya berupa kata benda dan dapat diidentifikasikan
dengan menganalisa kebutuhan user. Ditahap ini
diidentifikasikan obyek-obyek utama. Sedangkan kata benda
yang berupa atribut dari suatu obyek tidak diidentifikasikan
sebagai obyek tersendiri.
Hasil analisa terhadap tipe entitas, dimasukkan ke dalam kamus
data. Penamaan entitas harus mudah dimengerti dan
menggambarkan obyek yang sesungguhnya bagi user.
1.2 Mengidentifikasikan tipe relationship
Tujuan: mengidentifikasikan relasi penting yang ada diantara
tipe-tipe entitas yang telah teridentifikasikan. Hal-hal yang perlu
dilakukan pada tahap ini:
35
- Menggambarkan entitas yang telah ditentukan di tahap
sebelumnya, dan menentukan hubungan antara entitas
dengan menggunakan diagram ER (Entity Relatitonship).
- Menentukan batasan multiplicity dari tiap relationship.
Multiplicity adalah angka yang menggambarkan batasan
jumlah obyek yang memiliki hubungan dengan obyek lain
yang terjadi dalam suatu relationship. Batasan jumlah yang
menentukan jumlah obyek yang terlibat dalam suatu
relationship, akan menjadi batasan untuk menentukan
apakah penyimpanan dan manipulasi data valid atau tidak.
Multiplicity digunakan untuk memeriksa dan memelihara
kualitas data.
- Memeriksa dan menghilangkan fan traps. Fan traps adalah
keadaan dimana sebuah model mempresentasikan
relationship antar tipe entitas, yang menimbulkan kerancuan
hubungan antara entitas tersebut. (Connoly, 2002, p352).
Fan traps dapat diatasi dengan mengatur kembali hubungan
antar entitas:
• Memeriksa apakah setiap entitas setidaknya terhubung
dalam satu relationship.
• Mendokumentasikan tipe relationship.
1.3 Mengidentifikasikan dan mengasosiasikan atribut dengan suatu
entitas atau tipe relationship
36
Tujuan: Menghubungkan atribut dengan tipe entitas atau
relationship yang sesuai.
Beberapa hal yang harus diperhatikan dalam menentukan
atribut:
- Menentukan apakah atribut tersebut termasuk simple atau
composite attribute. Suatu atribut dapat didentifikasikan
sebagai composite attribute jika dapat dibagi menjadi
beberapa attribute yang lebih kecil (Simple Attribute).
- Menentukan apakah atribut tersebut termasuk single atau
multi-valued attribute. Bila suatu atribut dinilai perlu
memiliki lebih dari satu nilai atau suatu obyek, atribut
tersebut dapat diidentifikasikan sebagai multi-valued
attribute.
- Mengidentifikasikan derived attribute. Untuk menjaga
keakuratan derived attribute, harus didokumentasikan
atribut apa saja yang menghasilkan derived attribute dan
kapan derived attribute harus di-update. Hal ini akan
dibahas lebih lanjut ditahap konseptual.
- Masalah potensial. Bila suatu atribut diasosiasikan dengan
satu tipe entitas atau relationship, hal ini menunjukkan
bahwa:
• Ada beberapa entitas yang dapat direpresentasikan
sebagai satu entitas. Jika kedua entitas tersebut memiliki
37
beberapa atribut yang sama dan beberapa atribut yang
unik, salah satu entitas tersebut dapat digeneralisasi.
• Mengidentifikasi relationship antar tipe entitas. Contoh:
table staff dengan atribut StaffNo, StaffName, dan
Position. Dan table PropertyForRent dengan atribut
PropertyNo, Steer, City, Type, Rooms, Rent, dan
ManagerName. Atribut ManagerName dimaksudkan
untuk menggambarkan hubungan Staff manages
PropertyForRent dan relationship manages harus
ditambahkan pula.
- Dokumentasi atribut meliputi:
• Nama atribut dan deskripsi.
• Tipe data dan ukuran field.
• Alias / nama lain atribut.
• Apakah atribut tersebut simple atau composite attribute.
• Apakah atribut tersebut single atau multi-valued attribute.
• Apakah atribut tersebut termasuk derived attribute.
• Nilai default attribute.
1.4 Menentukan domain attribute
Tujuan: menentukan domain untuk atribut di model data
konseptual lokal.
Domain: kelompok nilai yang menjadi struktur suatu atribut.
38
1.5 Menentukan atribut candidate dan Primary key
Tujuan: mengidentifikasi candidate key untuk setiap entitas.
Jika ada lebih suatu candidate key, maka akan dipilih salah satu
untuk menjadi Primary key.
1.6 Mempertimbangkan penggunaan konsep permodelan yang lebih
tinggi
Tujuan: mempertimbangkan konsep permodelan yang lebih
baik, seperti generalisasi, spesialisasi, agregasi dan
composition.
Mendefinisikan entitas dalam diagram ER dengan konsep:
- Generalisasi / Spesialisasi: hubungan antar entitas yang
meminimalkan perbedaan dengan mengidentifikasikan
karakteristik yang sama. Dalam generalisasi, entitas yang
lebih umum disebut sebagi super class. Sedangkan entitas
yang lebih spesifik / khusus disebut sub class.
- Agregasi: hubungan antara entitas yang menggambarkan
hubungan “bagian dari” atau “memiliki”, dimana salah satu
entitas sebagai keseluruhan dan entitas yang lain sebagai
bagiannya.
- Composition: bentuk yang lebih spesifik dari agregasi
dimana ada hubungan kepemilikan yang kuat.
39
1.7 Memeriksa model akan kemungkinan redudansi
Periksa kembali hubungan:
- 1 to 1: untuk menghindari kemungkinan adanya dua entitas
yang mempresentasikan obyek yang sama meskipun nama
entitas tersebut mungkin berbeda.
- Menghilangkan relationship yang redundan untuk
menyederhanakan model data konseptual.
1.8 Memvalidasikan model konseptual lokal dengan transaksi user
Tujuan: memastikan model konseptual lokal, mendukung
transaksi yang dibutuhkan oleh view.
Model data lokal: Gambaran dari data yang diperlukan oleh
setiap bagian dalam suatu perusahaan.
Untuk mengecek apakah model konseptual telah
mempresentasikan transaksi-transaksi yang dibutuhkan oleh
user, digunakan dua pendekatan:
- Mendeskripsikan transaksi
- Mengecek apakah semua informasi (entitas, atribut, dan
relationship) yang ada dalam suatu transaksi telah di
dokumentasikan oleh model data.
- Menggunakan alur transaksi.
40
- Mengecek alur transaksi dalam model data (diagram ER).
Sehingga dapat diketahui bagian-bagian dari model yang kritis
terhadap transaksi, bagian yang perlu ditambahkan atau
diperbaiki entitas, atribut atau relationshipnya.
1.9 Membahas ulang model data konseptual lokal dengan user
Tujuan: memastikan bahwa model merepresentasikan view
dengan benar.
Tahap ini memeriksa apakah dalam model data terdapat
anomaly atau tidak. Bila masih ditemukan anomaly, tahap
perancangan sebelumnya dapat di ulang kembali. Tahap
perancangan dapat dilakukan hingga model data dianggap
merepresentasikan keadaan sebenarnya oleh user.
B. Logical Database Design
Logical Database Design adalah proses konstruksi suatu
informasi yang digunakan dalam perusahaan berdasarkan sebuah
model yang spesifik, tetapi bebas dari fakta-fakta DBMS dan
pertimbangan-pertimbangan fisik lainnya. Langkah-langkahnya
sebagai berikut:
Langkah 2: Buat dan validasikan model data logikal lokal untuk
setiap gambarannya
41
2.1 Menghilangkan fitur-fitur yang tidak sesuai dengan model
relasional
Tujuan dari tahap ini:
- Menghilangkan many to many binary relationship (*: *).
- Menghilangkan many to many recursive relationship (*: *).
Recursive relationship adalah hubungan suatu entitas dengan
entitas itu sendiri.
- Menghilangkan tipe relationship yang kompleks.
- Menghilangkan multi-valued attribute
2.2 Membuat relasi untuk model data logikal lokal
Tujuan: membuat relasi bagi model data logikal lokal yang
memperesentasikan entitas, relationship, atribut-atribut yang
telah diidentifikasi
2.3 Memvalidasikan relasi menggunakan normalisasi
Tujuan: memvalidasikan relasi yang model data logikal lokal
dengan menggunakan teknik normalisasi.
2.4 Memvalidasikan relasi pada transaksi-transaksi user
42
Tujuan: memastikan relasi yang ada pada model data logikal
lokal mendukung transaksi yang diperlukan oleh user.
2.5 Mendefinisikan integrity constraints
Tujuan: mendefinisikan batasan integritas yang ada dalam view.
2.6 Meninjau ulang model data logikal lokal dengan user
Tujuan: memastikan model data logikal lokal dan dokumentasi
pendukung yang menjelaskan model data adalah representasi
sebenarnya dari view.
Langkah 3: buat dan validasikan model data logikal lokal
Tujuan: menggabungkan tiap model data logikal lokal ke dalam
satu model data logikal global yang menggambarkan keseluruhan
perusahaan.
Model data global adalah gambaran dari data yang diperlukan oleh
user secara kesuluruhan.
3.1 Menggabungkan model-model data logikal lokal ke dalam
model data global
Aktifitas-aktifitas dalam tahap ini:
- Mengkaji ulang isi dari entitas atau relasi dan candidate key
43
- Mengkaji ulang nama dari relationship / foreign key
- Menggabungkan entitas / relasi dari model data lokal
- Memasukkan (tanpa menggabungkan) relationship / foreign
key yang unik dari model data lokal
- Menggabungkan relationship / foreign key dari model data
lokal
- Memeriksa entitas relationship dan relationship / foreign
key yang hilang
- Memeriksa foreign key
- Memeriksa batasan integritas
- Menggambarkan diagram ER global
- Meng-update dokumentasi
3.2 Memvalidasikan model data logikal global
Tujuan: memvalidasikan relasi yang terbentuk dari model data
logikal global dengan menggunakan teknik normalisasi, dan
untuk memastikan relasi tersebut mendukung transaksi yang
diperlukan.
3.3 Memeriksa pertumbuhan masa depan
Tujuan: menentukan apakah ada perubahan penting yang perlu
dilakukan di masa yang akan datang dan mengukur apakah
model data logikal global dapat menyesuaikan dengan
perubahan tersebut.
44
3.4 Meninjau ulang model data logikal global dengan user
Tujuan: memastikan bahwa model data logikal global dapat
menggambarkan keseluruhan perusahaan.
C. Physical Database Design
Physical Database Design merupakan proses pembuatan
deskripsi dari implementasi basis data pada media penyimpanan
sekunder, fase ini menggambarkan dasar relasi, berkas organisasi,
dan index untuk mencapai akses data yang efisien, dan beberapa
batasan hubungan yang mutu dan tingkatan keamanan. Langkah-
langkahnya sebagai berikut:
Langkah 4: menterjemahkan model data logikal global ke DBMS
4.1 Merancang base relations
Tujuan: membuat skema basis data relasional dari model data
logical global yang di implementasikan ke dalam DBMS.
4.2 Merancang representasi derived data
Tujuan: menentukan bagaimana derived data ditampilkan dalam
model data logikal global dengan target DBMS.
4.3 Merancang enterprise constraints
45
Tujuan: menentukan batasan perusahaan untuk target DBMS.
Langkah 5: merancang representasi fisikal
Tujuan: menentukan pengorganisasian file yang optimal dalam
menyimpan relasi dasar dan indeks yang dibutuhkan untuk
mencapai kinerja yang diinginkan.
5.1 Menganalisis transaksi
Tujuan: memahami fungsionalitas dan transaksi yang akan
dioperasikan dalam basis data dan untuk menganalisa transaksi
yang penting.
5.2 Memilih organisasi file
Tujuan: menentukan pengorganisasian yang efisien untuk setiap
relasi dasar.
5.3 Memilih indeks
Tujuan: menentukan apakah penambahan indeks akan
meningkatkan kinerja dari sistem.
5.4 Estimasi kebutuhan ruang disk
Tujuan: memperkirakan kapasitas penyimpanan yang
diperlukan oleh basis data.
46
Langkah 6: merancang user view
Tujuan: merancang tampilan user yang diidentifikasi sewaktu
pengumpulan kebutuhan dan tahap analisis dari siklus hidup
aplikasi basis data relasional. Dalam multi user DBMS, user view
memainkan peran yang sangat penting didalam mendefinisikan
struktur dari basis data dan menjalankan keamanan.
Langkah 7: merancang maknisme keamanan
Tujuan: merancang pengukuran keamanan untuk basis data yang
telah dispesifikasikan oleh user
Suatu basis data merupakan sumber daya perusahaan yang sangat
penting yang perlu dilindungi dengan menggunakan pengawasan
yang memadai. Beberapa masalah keamanan basis data yang perlu
diperhatikan:
- Pencurian data (Theft and Fraud)
- Kehilangan kerahasiaan suatu data (Loss of conffidentially)
- Kehilangan hak pribadi (Loss of privacy)
- Kehilangan integritas (Loss of Integrity)
- Kehilangan ketersediaan data (Loss of availability)
Langkah 8: pertimbangkan pengenalan control redundansi
47
Tujuan: menentukan apakah dengan mengenalkan redudansi dalam
sebuah cara pengendalian dapat mengendurkan aturan normalisasi
dan meningkatkan kinerja dari sistem.
Normalisasi merupakan suatu prosedur untuk menentukan atribut
mana yang mestinya bersama dalam sebuah relasi, oleh karena itu
normalisasi tidak boleh ditiadakan karena normalisasi merupakan
faktor yang terpenting dalam menentukan suksesnya sistem secara
keseluruhan. Hasil dari proses normalisasi adalah rancangan logikal
basis data yang struktural konsisten dan redudansi yang minimal.
Langkah 9: Mengawasi kinerja sistem
Tujuan: memantau sistem operasional dan meningkatkan kinerja
dari sistem untuk memperbaiki keputusan rancangan yang tidak
sesuai atau untuk menggambarkan kebutuhan akan perubahan.
Permulaan dari rancangan fisikal basis data tidak boleh dianggap
statis, akan tetapi harus dipertimbangkan sebagai sebuah perkiraan
dari kinerja operasional. Sekali permulaan rancangan telah
diimplementasikan, sangatlah diperlukan untuk memantau dan
memperbaiki sistem sebagai hasil dari pemantauan kinerja dan
syarat perubahan.
Pendekatan dalam perancangan basis data adalah:
48
- Pendekatan bottom-up
Pendekatan ini dimulai pada tingkat dasar dari atribut-atribut
(merupakan properti dari entitas dan relationship), yang melalui
analisis dari asosiasi antara atibut-atribut, yang dikelompokkan
ke dalam relasi yang mewakili tipe-tipe dari entitas-entitas dan
relationship antara banyak entitas.
- Pendekatan top-down
Pendekatan ini dimulai dengan pengembangan model data yang
terdiri atas beberapa entitas dan relationship high-level dan
kemudian menerapkan pendekatan top-down secara berturut-
turut untuk mengidentifikasi entitas, dan relationship lower-
level, serta atribut-atribut yang berhubungan.
- Pendekatan inside-out
Pendekatan ini berhubungan dengan pendekatan bottom-up
tetapi berbeda pada identifikasi awal entitas utama dan
kemudian menyebar ke entitas, relationship, dan atribut terkait
lainnya yang lebih dulu diidentifikasikan.
- Mixed strategy
Pendekatan ini menggunakan pendekatan bottom-up dan
pendekatan top-down untuk bagian yang berbeda dari model
sebelum akhirnya dikombinasikan bersama.
5. Pemilihan DBMS ( DBMS Selection )
Menurut Connoly dan Begg (2002, p284), tahap-tahap dalam
pemilihan DBMS, yaitu:
49
- Mempelajari DBMS-DBMS yang ada, yang sesuai dengan kriteria
kebutuhan user
- Membatasi pilihan DBMS menjadi 2 atau 3 pilihan.
Hal-hal yang menjadi pertimbangan dalam memilih produk DBMS
antara lain:
a. Anggaran yang dimiliki
b. Level dari dukungan yang akan diberikan vendor (pengembang
DBMS)
c. Kompatibilitas dengan software lain
d. Spesifikasi hardware yang harus dipenuhi untuk menjalankan
DBMS tersebut
- Evaluasi produk DBMS
Ada dua cara untuk mengevaluasi produk DBMS:
a. Memberi penilaian terhadap feature-feature dari setiap produk
DBMS. Pemilihan terhadap produk DBMS didasarkan pada
produk DBMS yang memiliki nilai total paling besar
b. Pengembang mendemonstrasikan produk DBMS dengan
melakukan pilot testing untuk mengetahui sejauh mana masing-
masing produk DBMS tersebut dapat memenuhi kebutuhan user
- Merekomendasikan produk DBMS yang terbaik dan membuat
dokumentasi dari tahapan pemilihan tersebut
6. Perancangan Aplikasi ( Application Design )
Menurut Connolly dan Begg (2002, p287), perancangan aplikasi
merupakan kegiatan mendesain user interface dan program aplikasi
50
yang menggunakan dan memproses basis data. Perancangan aplikasi
terdiri dari dua aktivitas penting yaitu:
• Perancangan Transaksi ( Transaction Design )
Transaksi merupakan sebuah aksi, atau sederetan aksi, yang
dilakukan oleh pengguna tunggal atau program aplikasi, yang
mengakses atau mengubah isi dari basis data. Kegunaan dari
perancangan transaksi adalah untuk mendefinisikan dan
mendokumentasikan karakteristik high-level dari transaksi yang
dibutuhkan basis data, diantaranya:
- data yang akan digunakan oleh transaksi
- karakteristik fungsional dari transaksi
- output dari transaksi
- keuntungan bagi user
- tingkat kegunaan yang diharapkan
Aktifitas ini dilakukan pada awal proses desain untuk meyakinkan
bahwa implementasi basis data dapat mendukung semua transaksi
yang dibutuhkan.
Terdapat tiga tipe transaksi, yaitu:
a. Retrieval transaction
Digunakan untuk memanggil data untuk ditampilkan pada layar
atau dalam laporan produksi
b. Update transaction
Digunakan untuk menambah record baru, menghapus record
lama, atau mengubah record yang sudah ada dalam basis data
51
c. Mixed transaction
Meliputi pemanggilan dan perubahan data
• Pedoman Perancangan User Interface (User Interface
Design Guidelines)
Beberapa aturan pokok dalam mendesain user interface,
yaitu:
a. Memilih judul yang menggambarkan tujuan dari
formulir / laporan
b. Menyediakan petunjuk dalam menggambarkan tujuan
dari formulir / laporan
c. Menyediakan fasilitas help untuk memberikan
penjelasan lebih lanjut
d. Meletakkan field dalam suatu formulir / laporan
berdasarkan urutan yang logis
e. Membuat tampilan formulir / laporan yang konsisten
f. Memperhatikan pemberian nama field agar familiar bagi
user
g. Menggunakan istilah dan singkatan secara konsisten
h. Memperhatikan penggunaan warna agar konsisten
i. Memberi batasan terhadap panjang field yang akan diisi
j. Memberikan kemudahan bagi user untuk memindahkan
kursor pada formulir / laporan
k. Memberikan kemudahan bagi user untuk meng-edit nilai
field
52
l. Menampilkan pesan kesalahan bila terjadi kesalahan
penginputan data
m. Memberikan tanda terhadap field optional
n. Membuat kotak pesan yang menjelaskan mengenai
pengisian field pada saat menempatkan kursor di field
yang akan diisi
o. Memberi sinyal yang menunjukkan bahwa pengisian
formulir lengkap dan valid
7. Prototyping
Menurut Connolly dan Begg (2002, p291), prototyping yaitu
membangun sebuah model kerja dari aplikasi basis data, yang
memungkinkan desainer atau pengguna untuk memvisualisasikan dan
mengevaluasi bagaimana sistem akhir akan tampak dan berfungsi.
Tujuan utama dari pembuatan prototyping adalah:
a. Untuk mengidentifikasikan fitur dari sistem apakah berjalan dengan
baik atau tidak.
b. Untuk memberikan perbaikan-perbaikan atau menambahkan fitur
baru.
c. Untuk klarifikasi kebutuhan user.
d. Untuk evaluasi feasibilitas (kemungkinan yang akan terjadi) dari
desain sistem tertentu.
Terdapat dua strategy prototyping yang digunakan saat ini, yaitu:
53
- Requirement prototyping -> menggunakan prototype untuk
menentukan kebutuhan dari aplikasi basis data yang diinginkan dan
ketika kebutuhan terpenuhi prototype akan dibuang.
- Evolutionary prototype -> digunakan untuk tujuan yang sama,
perbedaannya adalah prototype tidak dibuang ketika kebutuhan
terpenuhi tetapi dikembangkan lebih jauh menjadi aplikasi basis
data yang digunakan.
8. Implementasi (Implementation)
Menurut Connoly dan Begg (2002, p292), implementasi
merupakan realisasi fisik dari basis data dan desain aplikasi.
Implementasi basis data dicapai dengan menggunakan:
- Data Definition Language (DDL) digunakan untuk membuat skema
basis data atau file basis data kosong, dan juga untuk
mengimplementasikan user view yang diinginkan
- Third Generation Language atau Fourth Generation Language
(3GL atau 4GL) digunakan untuk membuat program aplikasi,
termasuk transaksi basis data yang disertakan dengan menggunakan
Data Manipulation Language (DML), atau ditambahkan pada
bahasa pemrograman.
9. Konversi Data dan Loading (Data Conversion and Loading)
Menurut Connoly dan Begg (2002, p292), konversi data dan
loading merupakan pemindahan data yang ada ke dalam basis data yang
baru dan mengkonversikan dengan beberapa aplikasi yang ada agar
54
dapat dijalankan pada basis data yang baru. Tahapan ini dibutuhkan
hanya ketika sistem basis data yang baru ditempatkan pada sistem yang
lama. Pada saat ini, DBMS biasanya memiliki manfaat untuk
memanggil file yang sudah ada ke dalam basis data yang baru. Dapat
juga untuk mengkonversi dan menggunakan program aplikasi dari
sistem lama untuk digunakan oleh sistem baru.
10. Pengujian (Testing)
Suatu proses eksekusi program aplikasi dengan tujuan untuk
mencari kesalahan. Dengan menggunakan strategi tes yang
direncanakan dan dengan data yang sesungguhnya. Pengujian hanya
akan terlihat jika terjadi kesalahan software.
11. Operational Maintenance
Menurut Connolly dan Begg (2002, p293), operational
maintenance merupakan proses mengawasi dan memelihara sistem
setelah instalasi. Aktivitas-aktivitas yang terdapat pada operational
maintenance meliputi:
- Mengawasi kinerja sistem, jika kinerja turun dibawah level yang
diterapkan maka memerlukan perbaikan atau pengaturan ulang
basis data.
- Memelihara dan memperbaharui aplikasi basis data (jika
dibutuhkan). Kebutuhan baru dimasukkan kedalam aplikasi basis
data melalui langkah-langkah terdahulu pada life cycle.
55
2.2 Teori-Teori Khusus
2.2.1 Pembelian
Menurut Mulyadi (2001, p299), sistem pembelian digunakan dalam
perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan.
Fungsi yang terkait dalam sistem pembelian adalah:
1. Fungsi Gudang: bertanggung jawab untuk mengajukan permintaan
pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk
menyimpan barang yang telah diterima oleh fungsi penerimaan.
2. Fungsi Pembelian: bertanggung jawab untuk memperoleh informasi
mengenai harga barang, menentukan pemasok yang dipilih dalam
pengadaan barang, mendapatkan informasi mengenai permintaan
pembelian dari gudang dan mengeluarkan order pembelian kepada
pemasok yang dipilih.
3. Fungsi Penerimaan: bertanggung jawab untuk memeriksa kualitas, jenis
dan kuantitas barang yang diterima dari pemasok dengan tujuan untuk
menentukan dapat tidaknya barang tersebut diterima oleh perusahaan yang
akan digunakan untuk proses produksi.
4. Fungsi Akuntansi: fungsi yang terkait dalam transaksi pembelian adalah
fungsi pencatat hutang dan fungsi pencatat persediaan. Fungsi pencatat
hutang bertanggung jawab untuk mencatat transaksi pembelian ke dalam
register bukti kas keluar dan untuk menyelenggarakan arsip dokumen
sumber (bukti kas keluar) yang berfungsi sebagai catatan hutang atau
menyelenggarakan kartu hutang sebagai buku pembantu hutang. Fungsi
56
pencatat persediaan bertanggung jawab untuk mencatat harga pokok
persediaan barang yang dibeli ke dalam kartu persediaan.
Menurut Mulyadi (2001, p301), jaringan prosedur dalam sistem
pembelian adalah:
1. Prosedur permintaan pembelian.
Dalam prosedur ini, fungsi gudang mengajukan permintaan
pembelian dalam formulir surat permintaan pembelian kepada fungsi
pembelian. Surat tersebut berisi sejumlah jenis barang-barang yang akan
dibeli. Surat tersebut akan dibuat dalam beberapa rangkap. Permintaan
pembelian tersebut akan dipenuhi tergantung dari keputusan manager
perusahaan yang bersangkutan.
2. Prosedur permintaan penawaran harga dan pemilihan pemasok.
Dalam prosedur ini, fungsi pembelian mengirimkan surat
permintaan penawaran harga kepada para pemasok untuk memperoleh
informasi mengenai harga barang dan berbagai syarat pembelian yang
lain, untuk memungkinkan pemilihan pemasok yang akan ditunjuk
sebagai pemasok barang yang diperlukan oleh perusahaan.
3. Prosedur order pembelian.
Dalam prosedur ini, fungsi pembelian mengirim surat order
pembelian kepada pemasok yang dipilih dan memberitahukan kepada
unit-unit organisasi lain dalam perusahaan (misalnya fungsi penerimaan,
fungsi yang meminta barang, dan fungsi pencatat hutang) mengenai
order pembelian yang sudah dikeluarkan oleh perusahaan.
57
4. Prosedur penerimaan barang.
Dalam prosedur ini, fungsi penerimaan melakukan pemeriksaan
mengenai jenis, kuantitas, dan mutu barang yang diterima dari pemasok,
dan kemudian membuat laporan penerimaan barang untuk menyatakan
penerimaan barang dari pemasok tersebut. Pada saat barang tersebut
diterima maka bagian akuntasi dan bagian persediaan akan berpengaruh.
5. Prosedur pencatat hutang.
Dalam prosedur ini, fungsi akuntansi memeriksa dokumen-
dokumen yang berhubungan dengan pembelian (surat order pembelian,
laporan penerimaan barang, dan faktur dari pemasok) dan
menyelenggarakan pencatatan hutang atau mengarsipkan dokumen
sumber sebagai catatan hutang.
6. Prosedur distribusi pembelian.
Prosedur ini meliputi distribusi rekening yang didebit dari
transaksi pembelian untuk kepentingan pembuatan laporan manajemen.
2.2.2 Penjualan
Menurut Mulyadi (2001, p202), penjualan mempunyai peranan
terpenting dalam perusahaan karena penjualan merupakan sumber
kelangsungan hidup suatu perusahaan. Semakin besar jumlah penjualan
semakin besar pula laba yang diperoleh. Penjualan terjadi apabila pihak
yang satu (penjual) menyerahkan hak milik suatu barang, sedangkan pihak
lain (pembeli) membayar barang baik secara tunai maupun kredit sebagai
58
imbalan dari perolehan hak milik tersebut. Kegiatan penjualan terdiri dari
transaksi penjualan barang atau jasa, baik secara tunai maupun kredit.
Fungsi penjualan antara lain:
a. Fungsi Penjualan
Dalam transaksi penjualan kredit, fungsi penjualan bertanggun g
jawab untuk menerima surat order dari pembeli, mengedit order dari
pelanggan untuk menambahkan informasi yang belum ada pada surat
order tersebut (seperti spesifikasi barang dan rute pengiriman) , meminta
otoritas kredit, menentukan tanggal pengiriman dan lokasi gudang
dimana barang akan dikirim, serta mengisi surat order pengiriman.
Fungsi ini juga bertanggung jawab untuk membuat back order pada saat
diketahui tidak tersedianya persediaan untuk memenuhi order dari
pelanggan.
b. Fungsi Kredit
Fungsi ini berada dibawah fungsi keuangan yang dalam transaksi
penjualan kredit bertanggung jawab untuk meneliti status kredit
pelanggan dalam memberikan otoritas pembelian kredit kepada
pelanggan.
c. Fungsi Gudang
Dalam transaksi penjualan kredit fungsi ini bertanggung jawab
untuk menyimpan barang dan menyiapkan barang yang dipesan oleh
pelanggan, serta menyerahkan barang ke fungsi pengiriman.
59
d. Fungsi Pengiriman
Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab
untuk menyerahkan barang atas dasar surat order pengiriman yang
diterimanya dari fungsi penjualan. Fungsi ini bertanggung jawab untuk
menjamin bahwa tidak ada barang yang keluar dari perusahaan tanpa
ada otoritas dari orang yang berwenang. Otoritas ini dapat berupa surat
order pengiriman yang telah ditanda tangani oleh fungsi penjualan,
memo debit yang ditangani oleh fungsi pembelian untuk barang
dikirimkan kembali kepada pemasok (retur pembelian), surat perintah
kerja dari fungsi produksi mengenai penjualan atau pembuangan aktiva
tetap yang sudah tidak dipakai lagi.
e. Fungsi Penagihan
Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab
untuk membuat dan mengirimkan faktur penjualan kepada pelanggan,
serta menyediakan copy faktur demi kepentingan pencatatan transaksi
penjualan oleh fungsi akuntansi.
f. Fungsi Akuntansi
Dalam Transaksi penjualan kredit, fungsi ini bertanggung jawab
untuk mencatat piutang yang timbul melalui transaksi penjualan kredit
dan membuat serta mengirimkan pernyataan piutang kepada debitur,
serta membuat laporan penjualan. Disamping itu, fungsi ini juga
bertanggung jawab untuk mencatat harga pokok persediaan yang dicatat
ke dalam kartu persediaan.
60
2.2.3 Persediaan
Menurut Mulyadi (2001, p553), sistem persediaan bertujuan untuk
mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini
berkaitan erat dengan sistem pembelian, sistem retur pembelian, dan sistem
akuntansi biaya produksi. Dalam perusahaan manufaktur, persediaan terdiri
dari persediaan produk jadi, persediaan produk dalam proses, persediaan
bahan baku, persediaan bahan penolong, persediaan bahan habis pakai
pabrik, dan persediaan suku cadang.
Ada dua macam metode pencatatan persediaan yaitu metode mutasi
persediaan (perpetual inventory method) dan metode persediaan fisik
(physical inventory method). Dalam metode mutasi persediaan, setiap
mutasi persediaan dicatat dalam kartu persediaan. Dalam metode
persediaan fisik, hanya tambahan persediaan dari pembelian saja yang
dicatat, sedangkan mutasi berkurangnya persediaan karena pemakaian tidak
dicatat dalam kartu persediaan.
Menurut Mulyadi (2001, p560), sistem dan prosedur yang
bersangkutan dengan sistem persediaan adalah:
1. Prosedur pencatatan produk jadi.
Prosedur ini merupakan salah satu prosedur dalam sistem
akuntansi biaya produksi. Dalam prosedur ini dicatat harga pokok
produk jadi yang didebitkan ke dalam rekening persediaan produk jadi
dan dikreditkan ke dalam rekening barang dalam proses. Catatan
akuntansi yang digunakan adalah kartu gudang, kartu persediaan, dan
jurnal umum.
61
2. Prosedur pencatatan harga pokok produk jadi yang dijual.
Prosedur ini merupakan salah satu prosedur dalam sistem
penjualan disamping prosedur lainnya seperti prosedur order
penjualan, prosedur persetujuan kredit, prosedur pengiriman barang,
prosedur penagihan, prosedur pencatatan piutang. Catatan akuntansi
yang digunakan adalah kartu gudang, kartu persediaan, jurnal umum.
3. Prosedur pencatatan harga pokok produk jadi yang diterima kembali dari
pembeli.
Prosedur ini merupakan salah satu prosedur yang membentuk
sistem retur penjualan. Jika produk jadi yang telah dijual dikembalikan
oleh pembeli, maka transaksi retur penjualan ini akan mempengaruhi
persediaan produk jadi. Catatan akuntansi yang digunakan adalah: kartu
gudang, kartu persediaan, dan jurnal umum atau jurnal retur persediaan,
jika perusahaan menggunakan jurnal khusus.
4. Prosedur pencatatan tambahan dan penyesuaian kembali harga pokok
persediaan produk dalam proses.
Pencatatan persediaan produk dalam proses umumnya dilakukan
oleh perusahaan pada akhir periode, pada saat dibuat laporan keuangan
bulanan dan laporan keuangan tahunan.
5. Prosedur pencatatan harga pokok persediaan yang dibeli.
Prosedur ini merupakan salah satu prosedur yang membentuk
sistem pembelian. Dalam prosedur ini dicatat harga pokok persediaan
yang dibeli.
62
6. Prosedur pencatatan harga pokok persediaan yang dikembalikan kepada
pemasok.
Prosedur ini merupakan salah satu prosedur yang membentuk
sistem retur pembelian. Jika persediaan yang telah dibeli dikembalikan
kepada pemasok, maka transaksi retur pembelian ini akan
mempengaruhi persediaan yang bersangkutan.
7. Prosedur permintaan dan pengeluaran barang gudang.
Prosedur ini merupakan salah satu prosedur yang membentuk
sistem akuntansi biaya produksi. Dalam prosedur ini dicatat harga
pokok persediaan bahan baku, bahan penolong, bahan habis pakai
pabrik, dan suku cadang yang dipakai dalam kegiatan produksi dan
kegiatan non produksi.
8. Prosedur pencatatan tambahan harga pokok persediaan karena
pengembalian barang gudang.
Dalam prosedur ini, transaksi pengembalian barang gudan g
mengurangi biaya dan menambah persediaan barang di gudang. Jurnal
yang dibuat untuk mencatat transaksi tersebut adalah jurnal umum.
9. Sistem perhitungan fisik persediaan.
Sistem penghitungan fisik persediaan umumnya digunakan oleh
perusahaan untuk menghitung secara fisik persediaan yang disimpan di
gudang, yang hasilnya digunakan untuk meminta pertanggungjawaban
Bagian Gudang mengenai pelaksanaan fungsi penyimpanan, dan
pertanggungjawaban Bagian Kartu Persediaan mengenai keandalan
catatan persediaan yang diselenggarakannya, serta untuk melakukan
63
penyesuaian terhadap catatan persediaan di Bagian Kartu Persediaan.
Catatan akuntansi yang digunakan adalah kartu persediaan, kartu
gudang, dan jurnal umum.
Menurut Mulyadi (2001, p579), fungsi yang terkait dalam sistem
perhitungan fisik persediaan adalah:
1. Panitia penghitungan fisik persediaan, berfungsi untuk melaksanakan
penghitungan fisik persediaan dan menyerahkan hasil penghitungan
tersebut kepada bagian kartu persediaan untuk digunakan sebagai dasar
adjustment terhadap catatan persediaan dalam kartu persediaan.
2. Fungsi Akuntansi bertanggung jawab untuk:
a. Mencantumkan harga pokok satuan persediaan yang dihitung ke
dalam daftar hasil penghitungan fisik.
b. Mengkalikan kuantitas dan harga pokok per satuan yang tercantum
dalam daftar hasil penghitungan fisik.
c. Mencantumkan harga pokok total dalam daftar hasil penghitungan
fisik.
d. Melakukan adjustment terhadap kartu persediaan berdasar data hasil
penghitungan fisik persediaan.
e. Membuat bukti memorial untuk mencatat adjustment data persediaan
dalam jurnal umum berdasarkan hasil penghitungan fisik persediaan.
3. Fungsi Gudang bertanggung jawab untuk melakukan adjustment data
kuantitas persediaan yang dicatat dalam kartu gudang berdasarkan hasil
perhitungan fisik persediaan.