|
5
BAB 2
LANDASAN TEORI
2.1
Sistem Basis Data
2.1.1
Basis Data
Menurut Connolly & Begg (2002, p14), basis data adalah suatu
koleksi data yang saling berhubungan secara logikal dan sebuah deskripsi
data, yang dirancang untuk memenuhi kebutuhan informasi suatu
organisasi. Sedangkan pengertian lain menurut Connolly
&
Begg
(2002,
p14), basis data merupakan suatu tempat penyimpanan data tunggal,
besar yang dapat digunakan secara serentak oleh banyak departemen dan
user. Yang disebut sebagai user disini adalah orang yang
menggunakan
atau yang berkepentingan terhadap sistem basis data. Sehingga basis data
sudah tidak
lagi dimiliki oleh
satu departemen tetapi
merupakan
suatu
sumber yang dipakai bersama-sama.
Tujuan dari pembuatan basis data adalah meminimumkan
pengulangan dan mencapai suatu dependensi data. Dependensi data
adalah kemampuan
untuk membuat
suatu perubahan dalam struktur data
tanpa
membuat perubahan pada program yang memproses data.
Dengan
kata lain, basis data adalah suatu pembagian dari pengumpulan data-data
|
|
6
yang berhubungan secara logis , dan uraian dari data tersebut, dirancang
untuk memenuhi kebutuhan informasi dari suatu organisasi.
2.1.2
Model Relasional
Organisasi
data
dalam bentuk
tabel
atau
disebut
juga relation,
terdiri atas baris (row/tuple). Yang
merepresentasikan record dan kolom
(column) yang merepresentasikan atribut ( field).
Berbagai keuntungan yang dimiliki oleh basis data relasional
adalah:
•
Bentuknya sederhana sehingga mudah dimengerti (representasi
tabel).
•
Bentuknya
alami
(natural)
mudah
bagi
pengguna
untuk
melakukan berbagai operasi data (insert , update , delete).
Model relasional
merupakan
model yang paling sederhana
sehingga mudah dipahami
oleh pengguna,
serta
merupakan yang paling
populer saat ini. Model relasional ini menggunakan sekumpulan tabel dua
dimensi
atau berupa baris dan atribut. Relasi dirancang sedemikian
rupa
sehingga dapat menghilangkan kemubaziran data dan
menggunakan
kunci tamu untuk berhubungan dengan relasi lain.
|
|
7
2.1.3
Basis Data Relasional
Menurut
Connolly
&Begg
(2002,
p72-p74) basis data
relasional
terdiri
dari:
•
Entity
Suatu entity adalah sebuah tabel dengan kolom-kolom dan baris-
baris.
•
Atribut
Suatu atribut adalah sebuah nama kolom dari suatu relasi.
•
Domain
Sebuah
domain
merupakan
sekumpulan
nilai-nilai
yang
diperbolehkan bagi satu atau lebih atribut.
•
Tuple
Tuple merupakan sebuah baris dari sebuah relasi.
•
Derajat (degree)
Derajat dari suatu relasi adalah sejumlah atribut yang terkandung
di dalamnya.
•
Kardinalitas (cardinality)
Kardinalitas
dari
sebuah
relasi
adalah
sejumlah
tuple
yang
terkandung di dalamnya.
•
Relasi basis data
Suatu koleksi dari sejumlah relasi normalisasi dengan nama-nama
relasi yang jelas.
|
|
8
2.1.4
Sistem Manajemen Basis Data (Database Management System-
DBMS)
Menurut Connolly & Begg (2002, p16), sistem manajemen basis
data
adalah suatu
sistem
software
yang
memungkinkan
user
untuk
mendefinisikan, menciptakan, memelihara, dan mengontrol akses ke
basis data. Sedangkan menurut Silberschatz, Korth, dan Sudarshan (2002,
p1) sistem manajemen basis data adalah koleksi data
yang tidak terelasi
dan kumpulan program untuk mengakses data tersebut.
Secara khusus sistem manajemen basis data menyediakan
beberapa fasilitas sebagai berikut:
1. Mengizinkan user untuk mendefinisikan basis data, melalui Data
Definition Language (DDL).
2. Mengizinkan user untuk memasukkan, mengubah, menghapus,
dan
mengambil
data
dari
basis
data,
melalui Data Manipulation
Language (DML).
3. Menyediakan akses yang terkontrol ke basis data.
Terdapat beberapa keuntungan yang dapat diperoleh dari
sistem manajemen basis data sebagai berikut:
1. Mengontrol Pengulangan Data
Sistem tradisional
yang
berbasiskan
arsip
memboroskan
ruang
dengan
menyimpan
informasi
yang
sama
pada
lebih
dari
satu
berkas. Sedangkan,
basis data
menghapuskan pengulangan
|
|
9
tersebut dengan
menggabungkan
berkas-berkas
sehingga
salinan
yang berkali-kali dari data yang sama tidak disimpan.
2. Ketetapan data
Dengan menghapus atau mengontrol pengulangan, akan
mengurangi terjadinya resiko yang tidak konsisten.
3. Informasi yang lebih banyak dari sejumlah data yang sama
Dengan integritas dari data operasional, dimungkinkan
bagi
organisasi
untuk
memperoleh
informasi
tambahan
dari data
yang sama.
4. Berbagi data
Secara khusus, berkas-berkas dimiliki oleh orang atau
departemen
yang
menggunakannya. Pada keadaan
yang berbeda,
basis data merupakan milik seluruh organisasi dan dapat dipakai
secara bersama-sama oleh
seluruh user yang memiliki autorisasi.
Dengan cara
ini, lebih banyak user
yang saling berbagi banyak
data.
5. Meningkatkan integritas data
Integritas basis data berhubungan dengan validitas dan
konsistensi dari penyimpanan data. Integritas selalu dinyatakan
dalam hubungan
batasan-batasan, yang
merupakan
ketetapan
peraturan bahwa basis data tidak diperbolehkan untuk dilanggar.
6. Meningkatkan keamanan
Keamanan basis data
adalah perlindungan basis data dari
user
yang
tidak
berkuasa.
Tanpa ukuran keamanan
yang cocok,
|
|
10
integrasi menyebabkan data menjadi lebih mudah diserang
daripada sistem yang berbasiskan arsip.
7. Penguatan standar
Integrasi
memperbolehkan Database
Administrator untuk
menetapkan dan menjalankan
standar yang diperlukan. Hal ini
meliputi standar departemen, organisasi, nasional, atau
internasional untuk beberapa hal seperti format data untuk
memudahkan
pertukaran
data antar
sistem,
menamai
perkumpulan, memperbaharui prosedur, dan aturan akses.
8. Neraca ekonomi
Menggabungkan
semua
data operasional
organisasi
ke
dalam satu basis data dan menghasilkan suatu kumpulan aplikasi
yang
bekerja
pada
satu
sumber data ini, hal
ini
dapat
mengakibatkan penghematan biaya.
9. Neraca dari kebutuhan yang berselisih
Setiap user atau departemen memiliki kebutuhan yang
akan terlibat perselisihan dengan kebutuhan user lain.
10. Meningkatkan kemampuan akses dan respon data
Sebagai hasil pengintegrasian, data yang melintasi
batasan-batasan departemen secara langsung dapat diambil oleh
end-user. Ini menyediakan suatu sistem dengan kemungkinan
besar lebih dapat berfungsi, sebagai contoh, digunakan untuk
memberikan layanan yang lebih baik kepada end-user atau klien
organisasi.
|
|
11
11. Meningkatkan daya produksi
Sistem manajemen
basis
data
(DBMS)
menyediakan
banyak
fungsi
standar
dimana programmer
akan
secara
normal
menulis
di
dalam aplikasi
yang
berbasiskan
arsip.
Pada
tingkat
dasar, sistem manajemen basis data (DBMS) menyediakan semua
penanganan rutin dokumen tingkat rendah yang secara khusus
dalam program aplikasi.
Ketentuan
dari
fungsi-fungsi
ini
mengizinkan programmer untuk memusatkan pada fungsionalitas
tertentu yang diminta oleh user tanpa harus khawatir dengan seluk
beluk implementasi.
12. Meningkatkan pemeliharaan melalui data yang berdiri sendiri
Pada sistem berbasis arsip,
uraian
dari
data
dan
logika
yang digunakan untuk mengakses data dibuat pada setiap aplikasi
program, membuat program tergantung dari data yang digunakan.
Sebaliknya,
sistem manajemen
basis
data
(DBMS)
memisahkan
uraian data dari aplikasi, dengan membuat aplikasi bebas terhadap
perubahan pada uraian data.
13. Meningkatkan concurrency
Pada
beberapa
sistem
yang
berbasis
arsip,
jika
ada
dua
atau lebih user diperbolehkan untuk mengakses berkas yang sama
secara
serentak,
maka
kemungkinan
akses-akses
tersebut akan
mengganggu satu sama lainnya, sehingga mengakibatkan
hilangnya informasi atau bahkan hilangnya integritas. Banyak
sistem manajemen basis data (DBMS) mengatur akses basis data
|
|
12
secara bersama-sama dan memastikan bahwa masalah-masalah
tersebut tidak dapat terjadi.
14. Meningkatkan back up dan layanan pemulihan
Banyak sistem yang berbasis arsip menempatkan tanggung
jawab kepada user untuk memberikan tindakan dalam melindungi
data
dari
kerusakan
sistem komputer
atau
program aplikasi.
Sebaliknya,
sistem manajemen
basis
data
(DBMS)
memberikan
fasilitas
untuk
memperkecil
sejumlah proses yang hilang yang
mengikuti suatu kerusakan.
Adapun beberapa kekurangan yang terdapat pada sistem
manajemen basis data adalah sebagai berikut:
1. Kerumitan
Perlengkapan dari suatu fungsionalitas yang diharapkan
dari
suatu
sistem manajemen
basis
data
(DBMS)
yang
baik
membuat DBMS menjadi perangkat lunak yang rumit.
2. Ukuran
Kerumitan dan luasnya fungsionalitas menyebabkan
DBMS
menjadi suatu perangkat
lunak
yang
ukurannya
sangat
besar,
menempati banyak megabyte ruang disk dan menghendaki
sejumlah besar memori untuk beroperasi secara efektif.
3. Harga dari DBMS
Harga dari DBMS bervariasi, tergantung pada lingkungan
sekitarnya dan fungsionalitas yang disediakan.
4. Penambahan biaya perangkat keras
|
|
13
Keperluan penyimpanan disk untuk DBMS dan basis data
akan mengharuskan pembelian tambahan ruang penyimpanan.
5. Biaya konversi
Dalam situasi yang sama, biaya dari DBMS dan tambahan
perangkat keras akan menjadi tidak berarti, dibandingkan dengan
harga perubahan aplikasi yang ada untuk beroperasi pada DBMS
dan perangkat keras yang baru.
6. Kinerja
Secara
khusus,
sistem berbasis
arsip
ditulis
untuk
suatu
aplikasi khusus, seperti faktur. Hasilnya, kinerja
yang dihasilkan
baik. Bagaimanapun, DBMS dibuat menjadi lebih umum, untuk
memenuhi
lebih
dari
satu
aplikasi. Hasilnya adalah beberapa
aplikasi tidak akan beroperasi secepat biasanya.
7. Pengaruh yang kuat dari kerusakan
Pemusatan dari beberapa sumber menyebabkan sistem
mudah
untuk
diserang.
Mengingat
semua user
dan
aplikasi
bergantung pada ketersediaan DBMS,
kerusakan
dari
komponen
apapun dapat membawa operasi ke suatu penghentian.
2.1.5
RDBMS (Relational Database Management Systems)
Menurut Whitten (2004, p573), “ Saat ini, RDBMS digunakan
untuk mendukung pengembangan
dan pembangunan sejumlah besar
system informasi. Database relasional menyimpan data pada sekumpulan
|
|
14
tabel yang dihubungkan melalui foreign key. DDL dan DML pada
sebagian besar RDBMS digabungkan menjadi sebuah bahasa standar
yang dikenal sebagai SQL”.
Menurut Ridley & Eaglestone
(2001, p17),” Kebanyakan dari
DBMS yang di up to date disebut RDBMS. RDBMS sebenarnya
berdasarkan pada ide sederhana bagaimana informasi dapat
direpresentasikan
sebagai
nilai dalam table.
Sebuah
RDBMS
juga
mendukung fasilitas untuk melakukan query dan memanipulasi data pada
tabel. Bahasa standar internasional untuk RDBMS adalah SQL.
2.1.6
Kunci Relasional
Menurut Connolly & Begg (2002, p78-79) kunci relasi sangat dibutuhkan
untuk
mengidentifikasi satu atau
lebih atribut (disebut kunci relasi) yang
memiliki nilai unik setiap tuple dalam relasi. Macam-macam kunci relasi:
1. Candidate Key
Kunci kandidat adalah satu
atribut
atau
satu
set
minimal
atribut
yang
mengidentifikasikan secara unik suatu kejadian spesifik dari entitas.
2. Primary Key
Kunci primer adalah satu atribut atau satu set minimal atribut yang tidak
hanya mengidentifikasikan secara unik suatu kejadian spesifik, tetapi juga
dapat mewakili setiap kejadian dari suatu entitas.
3. Alternate Key
|
|
15
Kunci alternatif adalah kunci kandidat
yang tidak dipakai sebagai kunci
primer.
4. Foreign Key
Kunci tamu adalah satu atribut yang melengkapi satu hubungan
(relationship) yang menunjukkan ke induknya.
2.2
Perancangan Basis Data
2.2.1
Pengertian Perancangan Basis Data
Menurut Connolly & Begg (2002, p279), perancangan basis data
(database design) adalah proses pembuatan suatu desain untuk sebuah
basis data yang mendukung operasional dan sasaran suatu perusahaan.
Perancangan basis data dilakukan dengan berlandaskan pada
metodologi
perancangan basis data.
Menurut Connolly & Begg (2002, p418), metodologi perancangan
basis data adalah sebuah pendekatan terstruktur yang menggunakan
prosedur, teknik, alat, dan alat bantu dokumentasi yang mendukung dan
memfasilitasi proses perancangan. Metodologi perancangan basis data
membantu perancang basis data
untuk
merencanakan,
mengatur,
mengendalikan , dan mengevaluasi proyek pengembangan basis data.
|
|
16
2.2.2
Pendekatan pada Perancangan Basis Data
Menurut
Connolly
&
Begg
(2002,
p279), ada dua
pendekatan
utama menuju perancangan basis data,yaitu:
1. Pendekatan bottom-up
Pendekatan bottom-up
dimulai
pada
tingkatan
dasar
dari
atribut (yang meliputi properties of entities dan relationships),
yang mana
melalui analisa di antara kumpulan atribut,
dikelompokkan menjadi relasi (relation)
yang
menggambarkan
jenis dari entitas dan relationship
di
antara
entitas. Proses dari normalisasi
menggambarkan
pendekatan
bottom-up ke perancangan basis data. Normalisasi melibatkan
pengenalan atribut yang diperlukan dan agregasi
(aggregation) yang selanjutnya menjadi relasi yang
ternormalisasi
didasarkan
pada
ketergantungan
fungsional
antar atribut. Pendekatan bottom-up cocok untuk perancangan
basis data yang sederhana dengan attribute yang secara relatif
sedikit.
2. Pendekatan top-down
Pendekatan
top-down dimulai
dengan
pengembangan
model
data
yang
berisi
beberapa
entitas dan
relationship
tingkat tinggi dan kemudian memakai pendekatan top-down
yang berturut-turut
untuk mengenali entitas,
relationship, dan
kumpulan tingkat rendah. Pendekatan top-down digambarkan
|
|
17
dengan
menggunakan
konsep entity-Relationship(ER)
model,
dimulai dengan pengenalan entitas dan relationship di
antara
entitas, yang mana demi kepentingan organisasi.
Ada pendekatan
lain
menuju
perancangan
basis
data
seperti
pendekatan inside-out
dan
pendekatan
pencampuran
strategi (mixed
strategy). Pendekatan inside-out
berhubungan
dengan
pendekatan
bottom-up tetapi
berbeda
dengan
pada
awalnya mengenali satu set entitas utama dan kemudian
menyebarkannya untuk mempertimbangkan entitas,
relationship dan
atribut
yang
lain yang
berhubungan dengan
yang pertama kali dikenali.
2.2.3
Tahapan Perancangan Basis Data
Menurut Connolly & Begg (2002, p419), proses perancangan dibagi
menjadi 3 tahap utama:
1. Perancangan basis data secara konseptual
Perancangan konseptual merupakan proses konstruksi
suatu
informasi
yang
digunakan
dalam sebuah
organisasi.
Fase
perancangan konseptual bermula dari pembuatan data model
konseptual dari organisasi, yang sepenuhnya bebas
mengimplementasikan rincian-rincian seperti mengenai sasaran
dari manajemen sistem basis data (DBMS), program-program
aplikasi, bahasa pemrograman, platform perangkat keras,
persoalan kinerja, atau pertimbangan-pertimbangan fisik lainnya.
|
|
18
2. Perancangan basis data secara logikal
Perancangan basis data logikal adalah proses konstruksi
suatu
informasi
yang
digunakan
dalam sebuah
perusahaan
berdasarkan pada sebuah model data yang spesifik, tetapi bebas
dari fakta-fakta DBMS dan pertimbangan-pertimbangan fisik
lainnya. Fase perancangan basis data secara logikal memetakan
model perancangan konseptual
pada sebuah
model
logikal,
yang
mana dipengaruhi oleh model data untuk target basis data
(contohnya , model relasional).
Model
data logikal
adalah
sumber
informasi
bagi
fase
perancangan
fisik,
menyediakan
perancangan fisik dengan
wahana untuk pembuatan penjualan yang sangat penting untuk
sebuah perancangan basis data yang efisien.
3. Perancangan basis data secara fisikal
Perancangan basis
data
secara
fisik
merupakan
proses
pembuatan deskripsi dari implementasi basis data pada media
penyimpanan sekunder. Fase ini mendeskripsikan dasar
relasi,berkas organisasi, dan indeks untuk mencapai pengaksesan
data yang efisien, dan beberapa batasan hubungan yang utuh dan
tingkatan keamanan.
|
|
19
2.2.4
Pemodelan Data
Menurut Connolly & Begg (2002, p280), dua tujuan utama dari
pemodelan
data
adalah
untuk
membantu
dalam pemahaman
arti
(semantics) dari data dan untuk memudahkan komunikasi tentang
kebutuhan informasi. Suatu data model mempermudah dalam
pemahaman arti data, dan kemudian data dimodelkan untuk memastikan:
a. Setiap perspektif user akan data.
b. Sifat data itu sendiri, gambaran fisik sendiri.
c. Fungsi data menguraikan user views.
Model
data
digunakan
untuk menyampaikan
pengertian
perancang akan kebutuhan informasi dari perusahaan. Model data
mendeskripsikan bagaimana perspektif user
terhadap
data dalam
database.
2.2.5
Entity Relational Diagram
Menurut
Date
C.J.
(2000,
p427-p429), entity-relational diagram
(E/R diagram) merupakan sebuah teknik untuk menggambarkan struktur
logic
dari
sebuah
basis
data
dalam suatu
cara
bergambar
Tentu
saja,
popularitas dari model E/R seperti sebuah pendekatan pada perancangan
basis
data
dapat dilengkapi
lebih
untuk
keberadaan
teknik
diagram
E/R
daripada untuk beberapa kasus lainnya.
Entity-relational
diagram (E/R
diagram)
digunakan
untuk
merepresentasikan entity dan bagaimana mereka berelasi satu sama lain
dengan
lebih
mudah.
Melalui
fase
perancangan
basis data,
sangat
|
|
20
direkomendasikan untuk menggunakan E/R diagram untuk membantu
membangun gambaran bagian-bagian perusahaan.
2.2.6
Normalisasi
Proses Normalisasi
Menurut Connolly & Begg (2002, p376) normalisasi adalah suatu
teknik untuk menghasilkan seperangkat relasi dengan 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 yang
lebih dikenal dengan anomali.
Pertama
kali
dikembangkan
oleh E.F Codd (1972b). Proses
normalisasi sering dilakukan sebagai rangkaian test terhadap suatu
hubungan
untuk
menentukan
apakah memenuhi
atau
melanggar
kebutuhan dari bentuk normal yang ditentukan.
Pada proses
normalisasi
seringkali
terjadi pemecahan sebuah
relasi
menjadi dua relasi atau
lebih. Proses pemecahan seperti ini
biasa
disebut dengan istilah dekomposisi. Secara lebih khusus, jenis
dekomposisi yang dilakukan adalah dekomposisi tak hilang, yang artinya
bahwa tidak ada informasi yang hilang ketika relasi dipecah menjadi
relasi-relasi lain.
1.
Bentuk normal kesatu (1NF)
|
|
21
Mengidentifikasi dan membuang
atribut
yang
berulang
(Repeating Group) dan memiliki nilai yang lebih dari satu (Multi
Value).
2.
Bentuk normal kedua (2NF)
Ketergantungan Fungsional (Functional Dependencies)
Menurut Connolly & Begg (2002, p379), bergantung
fungsional dapat didefinisikan sebagai berikut: Jika A dan B
merupakan bagian atribut dari suatu hubungan, B bergantung
penuh kepada A, jika dan hanya jika setiap nilai A berhubungan
dengan sebuah nilai B.
Bergantung
fungsional
penuh didefinisikan
sebagai
berikut:
Jika
A
dan
B
adalah atribut
dari
suatu
hubungan,
B
bergantung
fungsional
sepenuhnya kepada
A
jika
B
bergantung
fungsional
terhadap
A,
tetapi tidak
memiliki
ketergantungan
terhadap subset A lainnya.
3.
Bentuk normal ketiga(3NF)
Ketergantungan
transitif
(Transitive
Dependency)
Menurut Connolly & Begg (2002, p394), Suatu hubungan
berada pada bentuk normal ketiga jika:
a.
Berada pada bentuk normal pertama dan normal kedua
b.
Setiap atribut bukan kunci
tidak memiliki dependensi
transitif terhadap kunci primer.
4.
Bentuk normal keempat(4NF)
Ketergantungan Nilai Banyak ( Multi-Valued Dependency)
|
|
22
Menurut Connolly & Begg (2002, p407) Dapat
didefinisikan sebagai berikut:
A,B, dan C dalam suatu
hubungan,
jika
setiap
nilai
merupakan
bagian dari nilai B dan merupakan bagian dari nilai C.
Bagaimanapun,
setiap
bagian
dari nilai
B
dan
C
berdiri
sendiri
sendiri.
Menurut Connolly & Begg (2002, p408), suatu hubungan
dikatakan berada pada bentuk normal keempat jika suatu
hubungan:
a.Berada pada bentuk normal BCNF
b.Tidak
terdapat
dua
atau
lebih
atribut
yang
memiliki
ketergantungan nilai banyak (Multi Valued Dependency).
Meskipun BCNF telah membuang beberapa anomali, tidak
menutup kemungkinan bahwa bentuk BCNF akan
memiliki dua
atribut atau lebih yang bernilai banyak (Multi-Valued).
5.
Bentuk normal kelima(5NF)
Suatu hubungan dikatakan berada pada bentuk kelima jika
dan hanya jika suatu hubungan tidak memiliki dependensi dan
tidak dapat lagi dikomposisi menjadi relasi-relasi yang lebih kecil
dengan kunci kandidat yang tidak sama dengan kunci kandidat
relasi. Bentuk normal keempat dan kelima diperkenalkan oleh
Fagin (Fagin, 1977,
1979), hanya dipakai pada
kasus-kasus
khusus terhadap hubungan yang mengandung dependensi nilai
banyak.
|
 23
2.3
Siklus Hidup Aplikasi Basis Data (Database Application Lifecycle)
Sebagai
suatu
sistem basis
data
yang
merupakan
komponen dasar dari
organisasi yang lebih besar, luas sistem informasinya, siklus hidup aplikasi basis
data
secara
terpadu
dihubungkan
dengan
siklus
hidup
dari
sistem informasi.
Sangatlah penting untuk diperhatikan bahwa struktur dari siklus hidup dari
aplikasi
basis
data
tidaklah
harus benar-benar sekuensial, tetapi
terlibat
dalam
suatu perulangan dari bagian-bagian yang
sebelumnya
melalui
umpan
balik.
Berikut
adalah
gambar
dari
langkah-langkah
pada
siklus
hidup
aplikasi
basis
data:
|
 24
Gambar 2. 1 Langkah-langkah Pada Siklus Hidup Aplikasi Basis Data
(Sumber: Connolly & Begg, 2002, p272)
|
|
25
2.3.1
Pengumpulan dan Analisa Kebutuhan (Requirement Collection and
Analysis)
Ada banyak teknik untuk mengumpulkan informasi, disebut
dengan teknik pencarian fakta (fact-finding techniques). Informasi
dikumpulkan untuk setiap major user view meliputi:
•
Penguraian dari data yang digunakan atau dihasilkan
•
Perincian dari bagaimana data digunakan atau dihasilkan
•
Penambahan kebutuhan apa saja untuk aplikasi basis data yang baru
Informasi ini kemudian dianalisa untuk menentukan kebutuhan
yang akan dimasukkan ke dalam aplikasi basis data yang baru.
Kebutuhan-kebutuhan ini diuraikan secara bersama dalam dokumen yang
berhubungan sebagai spesifikasi kebutuhan untuk aplikasi basis data yang
baru.
Pengumpulan dan analisa kebutuhan merupakan tingkat
permulaan
menuju
perancangan
basis data. Sejumlah data dikumpulkan
tergantung pada sifat dari masalah dan kebijaksanaan dari perusahaan.
Informasi dikumpulkan pada tingkat ini mungkin menjadi struktur
yang kurang baik dan meliputi beberapa permintaan informal, yang harus
diubah menjadi suatu pernyataan kebutuhan yang lebih terstruktur. Ini
dicapai dengan menggunakan teknik spesifikasi kebutuhan, yang
meliputi, sebagai contoh:
Structured Analysis and Design (SAD)
techniques, Data Flow Diagram (DFD), and Hierarchical Input Process
Output (HIPO) charts yang didukung oleh dokumentasi.
|
|
26
Menurut Connolly & Begg (2002, p277), ada tiga pendekatan
utama untuk mengatur kebutuhan aplikasi basis data dengan banyak user
views, yaitu:
•
Pendekatan terpusat (the centralized approach)
Pendekatan terpusat
melibatkan penyusunan kebutuhan untuk
user
views
yang
berbeda
ke
dalam daftar tunggal
kebutuhan,
yang
tunjuk secara sederhana sebagai suatu pandangan (view). Pandangan
tersebut diberi suatu kumpulan nama yang menyediakan petunjuk dari
beberapa area yang fungsional yang dilindungi oleh semua gabungan
user
views. Biasanya,
pendekatan
ini
lebih disukai
ketika
ada
kebutuhan penting yang saling melengkapi untuk masing-masing user
views dan aplikasi basis data tersebut tidak terlalu kompleks.
•
Pendekatan integrasi pandangan (the view integration approach)
Dalam pendekatan integrasi pandangan, kebutuhan untuk masing-
masing user views biasanya untuk membangun suatu model data yang
terpisah
untuk menggambarkan user views. Biasanya, pendekatan ini
lebih disukai ketika ada perbedaan yang penting antara user views den
aplikasi basis data yang cukup kompleks untuk membenarkan
pembagian kerja menjadi bagian-bagian yang lebih teratur.
•
Kombinasi dari kedua pendekatan
2.3.2
Perancangan Basis Data Konseptual
Menurut Connolly & Begg (2002, p281), perancangan basis data
secara konseptual
yaitu proses
membangun suatu
model
informasi yang
|
 27
digunakan dalam suatu perusahaan, bebas dari semua pertimbangan fisik.
Adapun
tahapan perancangan
basis
data
konseptual
adalah sebagai
berikut:
1. Membangun dan memvalidasi model konseptual data lokal.
Untuk
membangun
sebuah model konseptual data
lokal secara spesifik.
1.1 Menentukan entity type
Mengidentifikasi entity
type
utama
yang
diperlukan.
Entity type
merupakan
kelompok
objek
yang mempunyai
properti-properti
yang
sama. Entity occurance merupakan objek yang secara unik
mengidentifikasi entity type.
Klasifikasi Entity:
Fisikal
Konseptual
1.2 Menentukan relationship type
Menentukan
hubungan penting
yang
terjadi di antara entity type
yang
telah
ditentukan.
Relationship
type merupakan
suatu
konsep
hubungan
yang
terjadi
antar
entity. Relationship
occurance merupakan
konsep hubungan yang secara unik mengidentifikasi relationship type.
1.3. Menentukan attribute dan domain attribute
Menghubungkan
attribute
dengan
entity
atau
relationship entity
yang
sesuai.
Attribute merupakan
properti dari entity
atau relationship
type. Domain attribute merupakan satu atau lebih set nilai yang dimiliki
oleh attribute.
1.4. Menentukan candidate key dan primary key
|
|
28
Menentukan
candidate key
untuk
tiap
entity type,
dan
jika
ada
candidate key lebih dari satu,
untuk memilih salah
satu sebagai primary
key. Candidate key merupakan set minimal attribute yang secara unik
mengidentifikasi occurance
dari entity
type.
Primary
key
merupakan
candidate key yang terpilih untuk mengidentifikasi occurance entity type.
1.5. Mempertimbangkan penggunaan model enhance (optional)
Mempertimbangkan
penggunaan
model
enhance,
seperti
specialization/ generalization, aggregation, dan composition. Pada
tahap
ini, digunakan proses specialization/generalization. Proses specialization
merupakan proses pembeda maximizing antara anggota entity dengan
identifikasi karakter pembeda. Proses generalization merupakan proses
pembeda
minimizing
antara
anggota
entity dengan
identifikasi
karakter
umum.
1.6. Memeriksa pengulangan
Memeriksa jika terdapat pengulangan pada model. Hal yang perlu
dilakukan pada tahap ini:
•
Periksa ulang relasi 1:1
•
Menghilangkan pengulangan relationship
1.7. Review dengan transaksi
Me-review model konseptual data lokal mendukung transaksi
yang diperlukan.
Ada dua pendekatan :
• Menentukan transaksi
|
|
29
Menggunakan jalur transaksi
2.3.3
Perancangan Basis Data Logikal
Menurut Connolly & Begg (2002,p281), perancangan basis data
secara
logikal
yaitu
proses
membangun
suatu model
informasi
yang
digunakan
dalam suatu
perusahaan
berdasarkan
pada
model
data
yang
spesifik, tetapi bebas dari DBMS tertentu dan pertimbangan-
pertimbangan fisik lainnya.
Tahapan-tahapan perancangan basis data logikal adalah sebagai berikut:
1. Membangun dan memvalidasi model logikal data lokal.
Membangun model logikal data lokal dari model konseptual data
lokal.
1.1. Hilangkan feature yang tidak kompatibel
Memperbaiki model konseptual data lokal dengan
menghilangkan feature yang tidak kompatibel. Feature yang tidak
kompatibel:
•
Relasi biner *:*
•
Relasi rekursif *:*
•
Relasi kompleks
•
Relasi yang mempunyai attribute multi-value
1.2. Menentukan relationship untuk model logikal data lokal
|
|
30
Membuat
hubungan
untuk
model logikal data lokal untuk
mewakili
entity,
relationship
dan
attribute
yang
telah
ditentukan.
Hal yang perlu dilakukan:
•
Tentukan strong entity
Strong
entity
merupakan
entity
yang
keberadaannya
tidak
bergantung pada entity lain.
•
Tentukan weak entity
Weak entity merupakan entity yang keberadaannya bergantung
pada entity lain.
•
Relasi biner 1:*
•
Relasi biner 1:1
•
Relasi rekursif 1:1
•
Superclass/subclass
•
Relasi biner *:*
•
Relasi kompleks
•
Attribute multi-value
1.3. Memvalidasi relasi dengan normalisasi
Memvalidasi
hubungan
dalam
model
logikal
data
lokal
menggunakan teknik normalisasi.
1.4. Memvalidasi relasi melawan transaksi user
Untuk memastikan bahwa relasi dalam model logikal data
lokal mendukung transaksi yang dibutuhkan oleh view
1.5. Mendefinisikan integrity constraint
|
|
31
Untuk
mendefinisikan
integrity
constraint
yang
diberikan
dalam view
1.6. Review model logikal data lokal dengan user
Untuk
memastikan
bahwa
model data logikal lokal dan
mendukung dokumentasi yang menggambarkan bahwa model
adalah representasi dari view yang sesungguhnya.
2. Membangun dan memvalidasi model data logikal global
2.1
Menggabungkan
model
data
logikal
lokal
ke
dalam
model
global
2.2 Memvalidasi model data logikal global
2.3 Mengecek untuk pertumbuhan yang akan datang
2.4 Mereview model data logikal global dengan user
2.3.4
Perancangan Basis Data Fisikal
Menurut Connolly & Begg (2002, p282) perancangan basis data
secara fisikal yaitu proses menghasilkan gambaran dari pelaksanaan basis
data pada
penyimpan
sekunder;
yang
menguraikan relasi dasar, berkas-
berkas
organisasi
dan
indeks yang
digunakan
untuk
mencapai
pengaksesan yang efisien pada data, dan segala ukuran keamanan dan
batasan integritas yang berhubungan. Adapun tahapan-tahapan dalam
merancang fisikal basis data antara lain:
1.
Mewujudkan model logikal data global untuk DBMS
Membuat skema relasi basis data dari model logikal data global.
|
|
32
1.1 Desain relasi dasar
Memutuskan bagaimana
mempresentasikan relasi dasar
dalam
model logikal data global untuk DBMS.
1.2 Desain representasi data turunan
Memutuskan
bagaimana
mempresentasikan
data
turunan
dalam
model logikal data global untuk DBMS.
1.3 Desain kendala perusahaan
Mendesain kendala perusahaan untuk DBMS.
2.
Desain representasi fisikal
Menentukan file organisasi untuk menyimpan relasi dasar dan
indeks yang diperlukan.
2.1.
Analisa transaksi
Memahami fungsi dari transaksi yang akan digunakan dalam basis
data dan menganalisa transaksi yang penting.
2.2.
Memilih file organisasi
Memastikan file organisasi yang efisien untuk tiap relasi dasar.
2.3
Memilih indeks
Memastikan
apakah
penambahan
indeks
akan
meningkatkan
pelaksanaan sistem.
2.4
Memperkirakan kebutuhan sistem
Memperkirakan kebutuhan yang diperlukan sistem.
3.
Merancang user view
|
|
33
Merancang user view yang telah ditentukan pada tahapan
requirement collection and analysis
pada tahapan siklus hidup
aplikasi basis data.
4.
Merancang mekanisme keamanan
Merancang
mekanisme keamanan untuk basis data bagi user
secara spesifik.
5.
Mempertimbangkan perkenalan pengulangan terkontrol
Menentukan
apakah
perkenalan
pengulangan
terkontrol akan
meningkatkan pelaksanaan sistem.
a. Menghubungkan relasi 1:1
b. Menduplikasi attrinute dalam relasi 1:1
c. Menduplikasikan attribute foreign key dalam hubungan
1:1
d. Menduplikasi attribute dalam relasi *:*
e. Memperkenalkan kelompok berulang
f.
Menggabung tabel dengan hubungan dasar
g.
Membangun tabel extract
6.
Memonitor sistem operasi
Memonitor
sistem operasi
dan
meningkatkan pelaksanaan
sitem
untuk memperbaiki keputusan rancangan yang tidak sesuai.
|
|
34
2.3.5
Pemilihan DBMS (DBMS Selection)
Menurut Connolly & Begg (2002, p284), pemilihan DBMS
merupakan pemilihan dari DBMS tertentu untuk mendukunng aplikasi
basis
data.
Jika
tidak
ada
DBMS,
suatu
bagian
yang
tepat
dari
siklus
hidup yang mana untuk membuat suatu pemilihan adalah di antara tahap
perancangan basis data konseptual dan logikal.
Suatu pendekatan sederhana untuk pemilihan adalah
mencocokkan ciri-ciri DBMS terhadap kebutuhan. Dalam memilih suatu
produk DBMS baru, ada suatu kesempatan untuk memastikan bahwa
proses pemilihan adalah terencana dengan baik, dan sitem menyampaikan
manfaat yang nyata kepada perusahaan.
Memilih DBMS
Langkah-langkah utama dalam memilih suatu DBMS
•
Mendefinisikan batas-batas referensi pelajaran
•
Meringkas dua atau tiga produk
•
Evaluasi produk
•
Menganjurkan pemilihan dan menghasilkan laporan
2.3.6
Prototyping
Menurut
Connolly
&
Begg
(2002, p291)
Prototype
adalah
suatu
model kerja yang tidak biasanya memiliki semua gambaran yang
diperlukan
atau
menyediakan
semua
fungsionalitas
dari
sistem akhir.
Tujuan utama dari pengembangan suatu prototype aplikasi basis data
|
|
35
adalah
untuk
memperbolehkan
pemakai
untuk
menggunakan prototype
dalam
mengenali
gambaran
dari sistem yang
bekerja dengan
baik atau
yang tidak, dan jika memungkinkan
untuk
mengusulkan
peningkatan
bahkan gambaran yang baru untuk aplikasi basis data.
Menurut Connolly & Begg (2002, p292), ada 2 strategi
prototyping yang saat ini sering digunakan:
1. Requirement prototyping:
Menggunakan sebuah prototype untuk menentukan
kebutuhan dari aplikasi basis data yang dituju dan ketika semua
kebutuhan sudah lengkap, prototype akan dibuang.
2. Evolutionary protyping
Digunakan untuk tujuan yang sama, perbedaannya adalah
prototype
tidak dibuang,namun
pengembangan
lebih lanjut akan
menjadi aplikasi basis data
2.3.7
Implementasi (Inmplementation)
Menurut
Connolly
&
Begg
(2002, p292),
implementasi
adalah
realisasi fisikal dari basis data dan rancangan aplikasi. Pada penyelesaian
dari tahap-tahap perancangan, adalah untuk
mengimplementasikan
basis
data dan aplikasi program. Implementasi basis data adalah dengan
menggunakan Data Definition Language (DDL) dari DBMS yang telah
terpilih
atau Graphical
User
Interface
(GUI),
yang
memberikan
fungsionalitas
yang
sama
ketika
menyembunyikan
pernyataan DDL
|
|
36
tingkat rendah. Pernyataan DDL digunakan untuk membuat struktur basis
data dan berkas-berkas basis data yang kosong. User views yang khusus
juga diimplementasikan pada tahap ini.
Keamanan (security) dan pengaturan integrasi untuk aplikasi juga
diimplementasikan. Beberapa pengaturan diimplementasi dengan
menggunakan DDL, tetapi yang lainnya
mungkin perlu didefinisikan di
luar penggunaan DDL.
2.3.8
Pengujian (Testing)
Menurut Connolly & Begg (2002, p293), Pengujian ini
merupakan
proses dalam
menjalankan
aplikasi program
dengan
maksud
untuk mencari kesalahan (error). Sesungguhnya, pengujian tidak bisa
memperlihatkan ketidakadaan kesalahan, ia hanya bisa memperlihatkan
adanya kesalahan perangkat lunak (software). Jika pengujian diadakan
dengan sukses, ia akan menemukan kesalahan-kesalahan dengan aplikasi
program dan mungkin juga struktur basis datanya.
Seiring dengan perancangan basis data, user dari sistem baru
harus terlibat dalam proses pengujian. Situasi yang cocok untuk
pengujian
sistem adalah
dengan
melakukan
pengujian
basis
data
pada
sistem perangkat keras (hardware) yang terpisah, tetapi ini biasanya tidak
tersedia.
Jika
data
riil
digunakan,
adalah
penting
untuk
memiliki
cadangan (back up) dalam masalah kesalahan. Setelah pengujian selesai,
aplikasi sistem siap untuk diserahkan ke users.
|
|
37
2.4
Teori Pembelian, Penjualan dan Persediaan Barang
2.4.1
Teori Pembelian
Menurut Mulyadi (2001,p299), Pembelian digunakan dalam
perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan.
Transaksi pembelian dapat digolongkan menjadi dua yaitu pembelian
lokal dan impor. Pembelian lokal adalah pembelian dari pemasok dalam
negeri, sedangkan pembelian impor adalah pembelian dari pemasok luar
negeri.
Transaksi pembelian mencakup prosedur sebagai berikut :
1
Fungsi
gudang
mengajukan
permintaan
pembelian
ke
fungsi pembelian.
2
Fungsi pembelian meminta penawaran harga dari berbagai
pemasok.
3
Fungsi
pembelian
menerima
penawaran
harga
dari
berbagai pemasok dan melakukan pemilihan pemasok.
4
Fungsi pembelian membuat order pembelian kepada
pemasok yang dipilih.
5
Fungsi
pemeriksaan
memeriksa
dan
menerima
barang
yang dikirim oleh pemasok.
6
Fungsi penerimaan menyerahkan barang yang diterima
kepada fungsi gudang untuk disimpan.
7
Fungsi penerimaan melaporkan penerimaan barang kepada
fungsi akuntansi.
|
|
38
Fungsi akuntansi menerima faktur tagihan dari pemasok dan atas
dasar dari
faktur pemasok tersebut, fungsi akuntansi
mencatat kewajiban
yang timbul dari transaksi pembelian.
2.4.2
Teori Penjualan Kredit
Menurut Mulyadi (2001,p210), penjualan kredit dilaksanakan
oleh perusahaan dengan cara mengirimkan barang sesuai order 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 selalu didahului
dengan analisis terhadap dapat atau tidaknya pembeli tersebut diberi
kredit.
Prosedur yang membentuk sistem penjualan kredit adalah sebagai
berikut :
1
Prosedur order penjualan.
2
Prosedur persetujuan kredit.
3
Prosedur pengiriman.
4
Prosedur penagihan.
5
Prosedur pencatatan piutang.
6
Prosedur distribusi penjualan.
Prosedur pencatatan harga pokok penjualan.
|
|
39
2.4.3
Teori Persediaan Barang
Menurut
Mulyadi
(2001,p553),
Dalam perusahaan
manufaktur,
persediaan barang terdiri dari : persediaan produk jadi, persediaan produk
dalam proses,
persediaan
bahan
baku,
persediaan
bahan
penolong,
persediaan habis pakai pabrik, persediaan suku cadang.
Sistem dan prosedur
yang bersangkutan dengan sistem akuntansi
persediaan adalah :
1
Prosedur pencatatan produk jadi.
2
Prosedur pencatatan harga pokok produk jadi yang dijual.
3
Prosedur pencatatan harga pokok produk jadi
yang diterima
kembali dari pembeli.
4
Prosedur pencatatan tambahan dan penyesuaian kembali harga
pokok persediaan produk dalam proses.
5
Prosedur pencatatan harga pokok persediaan yang dibeli.
6
Prosedur pencatatan
harga pokok persediaan
yang dikembalikan
kepada pemasok.
7
Prosedur permintaaan dan pengeluaran barang gudang.
8
Prosedur pencatatan tambahan harga pokok persediaan karena
pengembalian harga gudang.
Sistem perhitungan fisik persediaan.
|