7 BAB 2 Tinjauan Pustaka 2.1 Teori yang Berkaitan

advertisement
BAB 2
Tinjauan Pustaka
2.1 Teori yang Berkaitan Dengan Database
2.1.1 Data
Seperti pendapat yang diungkapkan oleh Laudon dan Laudon
(2012:375), data merupakan kumpulan fakta-fakta kasar yang
menunjukkan kejadian yang terjadi dalam organisasi atau lingkungan
fisik sebelum fakta tersebut diolah dan ditata menjadi bentuk yang
dapat dipahami.
2.1.2 Database
Seperti yang disampaikan oleh Connolly dan Begg (2010:65),
bahwa database adalah kumpulan data yang saling terhubung secara
logis dan deskripsi dari data tersebut, dirancang untuk menemukan
informasi yang dibutuhkan oleh sebuah organisasi.
Dalam merancang database, salah satu hal yang perlu
diperhatikan adalah efisiensi. Banyaknya data yang redudansi dapat
mengurangai efisiensi pada database sehingga perlu dilakukan
normalisasi. Database ini digunakan tidak hanya oleh satu orang
maupun satu departemen, database dapat digunakan oleh seluruh
departemen dalam perusahaan. Database ini akan menjadi sumber
data yang digunakan secara bersama dalm perusahaan. Database tidak
lagi dimiliki oleh satu departemen tetapi sumber perusahaan yang
saling berbagi. Untuk mendapatkan database. Dengan hanya database
saja tidak cukup, diperlukan Database Management System (DBMS)
untuk dapat menggunakan database. Database bisa diartikan sebagai
suatu file data yang memiliki tabel, record, field, index, query, filter
dan view. Berikut adalah definisi umum isi sebuah file database.
7
8
1.
Tabel
Tabel adalah sekelompok record data, masing-masing
berisi informasi yang sejenis.
2.
Record
Record adalah entri tunggal dalam tabel. Bisa saja
disebut sebagai baris mengingat sebuah tabel terdiri dari baris
(record) dan kolom (field).
3.
Field
Field adalah item tertentu dalam tabel. Bisa disebut
sebagai kolom.
4.
Index
Index adalah field kunci yang ditujukan ke suatu record
yang spesifik serta diurutkan dalam urutan tertentu.
5.
Query
Query adalah perintah SQL yang dirancang untuk
memanggil kelompok record tertentu dari satu tabel/lebih.
6.
View
View merupakan tabel virtual yang berisi record dari
berbagai tabel. Fungsi utamanya untuk memudahkan untuk
mendapatkan data yang spesifik dari berbagai tabel.
2.1.3
DBMS (Database Management System)
Menurut Connolly dan Begg (2010:66), DBMS perangkat
lunak sistem yang dapat mendefinisikan, membuat, memelihara, dan
mengontrol akses ke basis data. Seperti yang dikatakan oleh Connolly
dan Begg (2010:99-104), fungsi daripada DBMS antara lain:
1.
Penyimpanan, Pengambilan, dan Update Data
DBMS harus menyediakan pengguna dengan kemampuan
untuk menyimpan, mengambil, dan update data dalam
database.
2.
Sebuah
User-Accessible
Pengguna)
Catalog
(Katalog
Data
untuk
9
Dalam DBMS harus menyediakan katalog yang mana berisi
deskripsi dari data yang disimpan di dalamnya dan informasi
mengenai siapa saja yang diberi hak akses untuk mengakses
data di dalamnya. Pada dasarnya yang disimpan dalam sistem
katalog terdiri dari:
a.
Nama, tipe, dan ukuran data.
b.
Nama hubungan.
c.
Batasan integritas dalam data.
d.
Nama pengguna yang memiliki hak akses ke basis data.
e.
Data yang dapat diakses pengguna dan tipe hak akses.
f.
Skema eksternal, konseptual, internal serta pemetaan
antar skema.
g.
3.
Statistik pemakaian.
Mendukung transaksi DBMS harus menyediakan sebuah
mekanisme yang dapat melakukan perubahan terhadap
transaksi yang sudah terjadi untuk user.
a. Layanan kontrol konkurensi
DBMS harus dapat membuat sebuah sebuah
cara kerja dimana dapat mengatur pengguna sehingga
saat pengguna merubah basis data bersamaan tidak
terjadi crash data.
b. Layanan perbaikan
Dalam
satu
DBMS,
harus
ada
mekanisme untuk memperbaiki basis
sebuah
data yang
bermasalah dengan menggunakan cara apa pun.
c. Layanan otorisasi
DBMS harus dapat menyediakan validasi untuk
dapat
memastikan
bahwa
user
yang
hendak
mengaksesnya itu memang sudah memiliki otoritas.
d. Mendukung komunikasi data
Sebuah DBMS harus dapat menghubungkan
antar perangkat lunak dimana digunakan untuk
komunikasi data.
e. Layanan integritas
10
Sebuah DBMS harus dapat menyediakan cara
untuk memastikan data dalam basis data dan perubahan
data tersebut dapat mengikuti peraturan yang telah
diatur sebelumnya.
f. Memberikan kemampuan independensi data
Pada DBMS harus memiliki fasilitas dimana
mendukung independensi program dari struktur basis
data.
g. Layanan utilitas
Sebuah DBMS harus menyediakan sekumpulan
layanan utilitas, seperti:
•
Fasilitas import data.
•
Fasilitas monitoring.
•
Program analisis statistik.
•
Fasilitas pengaturan ulang indeks.
4. Layanan kontrol konkurensi
DBMS harus menyediakan mekanisme untuk memastikan
bahwa database diperbarui dengan benar ketika beberapa
pengguna memperbarui database secara bersamaan.
5. Pemulihan layanan
DBMS harus memberikan mekanisme untuk memulihkan
database dalam hal database rusak dengan cara apapun.
6. Layanan otorisasi
DBMS harus menyediakan mekanisme untuk memastikan
bahwa hanya pengguna yang berwenang dapat mengakses
database.
7. Dukungan untuk komunikasi data
DBMS harus mampu mengintegrasikan dengan software
komunikasi.
8. Layanan integritas
DBMS harus memberikan sarana untuk memastikan bahwa
kedua data dalam database dan perubahan pada data mengikuti
aturan-aturan tertentu.
11
9. Layanan untuk mempromosikan independensi data
DBMS
harus
mencakup
fasilitas
untuk
mendukung
kemandirian program dari struktur aktual dari database.
10. Layanan utilitas
DBMS harus menyediakan satu set layanan utilitas.
2.1.3.1 Fasilitas DBMS (Database Management System)
Dari
penerapan
sebuah
DBMS,
tentunya
akan
mendapatkan fasilitas yang akan menguntungkan perusahaan
yang menerapkan DBMS itu sendiri. Diantaranya fasilitas yang
akan di dapatkan seperti yang dikutip dari Connolly dan Begg
(2010:66), fasilitas yang disediakan oleh DBMS antaralain :
1.
Data Definition Language (DDL) yang memungkinkan
pengguna untuk menspesifikasikan tipe dan struktur
data, serta batasan pada data yang disimpan dalam basis
data.
2.
Data
Manipulation
memungkinkan
Language
pengguna
(DML)
untuk
yang
memasukkan,
mengubah, menghapus, dan menampilkan data dari
basis data.
3.
Fourth-Generation
Languages
(4GLs)
yang
memungkinkan pengguna tidak melakukan apa yang
program lakukan, melainkan mendefinisikan parameter
untuk alat-alat yang menggunakan mereka untuk
menghasilkan program aplikasi.
2.1.3.2 Keuntungan
dan
Kekurangan
DBMS
(Database
Management System)
DBMS menjanjikan banyak keuntungan yang dapat
digunakan, namun tentunya DBMS juga memiliki kekurangan
yang
perlu
diperhatikan.
Pertama-tama
perlu
melihat
keuntungan apa saja yang diberikan oleh DBMS. Menurut
12
Connolly
dan
Begg
(2010:77-80),
keuntungan
dalam
menggunakan DBMS ialah:
1. Mengendalikan pengulangan data (control of data
redudancy)
Database
dimana
tempat
menampung
banyaknya data yang mana dari banyaknya data
tersebut memungkinkan adanya pengulangan data. Oleh
karena
itu
mengendalikan
dibutuhkannya
pengulangan
Database
data
dengan
dalam
cara
mengintegrasikan file sehingga berbagai data yang
sama tidak akan disimpan dalam database, akan tetapi
hal ini tidak menghilangkan semua pengulangan data
yang ada di database secara menyeluruh, melainkan
hanya membuat jumlah pengulangan data dapat
dikontrol.
2. Konsistensi data
Dengan mengontrol perulangan data, dapat
mengurangi resiko terjadinya ketidak konsistensian
yang terjadi. Jika data yang disimpan hanya sekali
dalam database, maka berbagai perubahan bagi nilai
data tersebut juga hanya dilakukan satu kali, dan nilai
tersebut harus tersedia kepada semua pengguna. Dan
jika item data yang disimpan lebih dari sekali dan
sistem menyadari hal ini, sistem ini dapat memastikan
bahwa semua salinan item disimpan secara konsisten.
3. Semakin banyak informasi yang didapat dari data yang
sama
Dengan mengintegrasikan data operasional,
dapat memungkinkan perusahaan untuk memperoleh
informasi tambahan dari data yang sama.
4. Pembagian data (Sharing of data)
Database merupakan bagian dari keseluruhan
organisasi dan dapat dibagikan ke semua pengguna
yang mempunyai wewenang.
13
14
5. Meningkatkan integritas data
Integritas data mengacu pada validitas dan
konsistensi data yang disimpan, integritas biasanya
diekspresikan dalam istilah batasan, yang berupa aturan
konsisten yang tidak boleh dilanggar oleh database,
dan dapat memungkinkan DBA untuk menjelaskan, dan
memungkinkan
DBMS
untuk
membuat
batasan
integritas.
6. Meningkatkan keamanan data
Meningkatkan
keamanan
data
dimana
memproteksi database dari user yang tidak memiliki
wewenang.
7. Penerapan standarisasi
Integrasi
memungkinkan
DBA
(Database
Administrator) untuk mendefinisikan dan membuat
standard yang diperlukan. Standarisasi ini termasuk
standarisasi departemen, organisasi, nasional, dan
internasional dalam hal format data, dan berguna untuk
memfasilitasi pertukaran data antara sistem, ketepatan,
penamaan standarisasi dokumentasi, prosedur update,
dan aturan pengaksesan.
8. Pengurangan biaya
Dimana semua data operasional organisasi
dipusatkan ke dalam database dan membuat aplikasi
yang
bekerja
menghasilkan
penyatuan
pada
satu
pengurangan
biaya
untuk
sumber
biaya.
data
Jadi
pengembangan
dapat
dengan
dan
pemeliharaan sistem pada setiap departemen akan
menghasilkan total biaya yang dikeluarkan akan lebih
rendah.
Sehingga
sisa
biaya
yang
merupakan
penghematan sebelumnya dapat digunakan untuk hal
lain yang dapat meningkatkan performa bagi kebutuhan
organisasi.
15
16
9. Menyeimbangkan konflik kebutuhan
Setiap pengguna mempunyai kebutuhan yang
mungkin berbeda dengan kebutuhan pengguna lain.
Oleh karena itu database dikendalikan oleh DBA
(Database Administrator), DBA juga yang akan
membuat keputusan berkaitan dengan perancangan dan
penggunaan operasional database yang menyediakan
penggunaan terbaik dari sumber daya bagi keseluruhan
organisasi.
10. Meningkatkan kemampuan pengaksesan dan respon
pada data
Dengan mengintegrasikan data yang melintasi
batasan departemen dapat langsung diakses oleh
pengguna akhir, hal ini dapat menyediakan sebuah
sistem dengan lebih banyak fungsi.
11. Meningkatkan produktivitas
DBMS menyediakan banyak fungsi standar
yang biasanya ditulis oleh programmer dalam aplikasi
berbasis file.
Pada tingkat
menyediakan
semua
dasar,
rutinitas
DBMS juga
tingkat
rendah
penanganan file yang khas dalam program aplikasi.
Fungsi-fungsi ini memungkinkan seorang programmer
untuk berkonsentrasi pada fungsi
tertentu yang
dibutuhkan oleh seorang pengguna. DBMS banyak juga
menyediakan lingkungan generasi keempat, yang
digunakan untuk menyederhanakan pengembangan
aplikasi database. Hal ini menyebabkan produktivitas
pemprogram meningkat dan waktu pengembangan
berkurang (dengan penghematan biaya yang terkait).
12. Meningkatkan pemeliharaan melalui data independensi
Dalam sistem berbasis file, deskripsi data dan
logika untuk mengakses data yang dibangun ke dalam
setiap program aplikasi, membuat program bergantung
17
pada data. Perubahan dengan cara data disimpan pada
disk dapat memerlukan perubahan besar untuk program
yang dipengaruhi oleh perubahannya. Sebaliknya,
DBMS memisahkan deskripsi data dari aplikasi,
sehingga membuat aplikasi kebal terhadap perubahan
dalam deskripsi data.
13. Meningkatkan konkurensi
DBMS juga digunakan untuk mengelola akses
database secara bersamaan dan memastikan bahwa
masalah seperti dua atau lebih pengguna yang diijinkan
untuk
mengakses file yang secara bersamaan akan
mengakibatkan hilangnya informasi dan integritas.
14. Meningkatkan backup dan perbaikan layanan
Backup
data
merupakan
hal
yang
perlu
diperhatikan karena untuk melindungi data dari
kegagalan sistem. Backup harus sering dilakukan
seiring dengan proses datanya dan apabila selama
pekerjaan telah
dipergunakan.
terjadi kegagalan maka backup
Dan
DBMS
modern
memberikan
fasilitas untuk meminimalkan jumlah pengolahan yang
hilang setelah terjadi kegagalan. Setelah melihat
keuntungan yang dimiliki DBMS, perlu melihat
kerukurangan
yang dimiliki
oleh
DBMS untuk
dipertimbangkan.
Menurut Connolly dan Begg (2010:80-81),
kerugian dalam menggunakan DBMS ialah :
1. Kompleksitas
Ketentuan dari fungsi yang diharapkan dari
DBMS yang baik membuat DBMS menjadi sebuah
software yang sangat kompleks, perancang dan
pengembang database, DA, dan DBA, serta pengguna
akhir
harus
memahami
fungsi
tersebut
untuk
mendapatkan banyak keuntungan dari DBMS tersebut.
18
19
2. Ukuran data yang besar
Fungsi yang kompleks dan luas membuat
DBMS menjadi software yang sangat besar, sehingga
memerlukan banyak ruang harddisk dan jumlah
memori yang digunakan menjadi sangat besar untuk
berjalan dengan efisien.
3. Biaya dari DBMS
Biaya
DBMS
bervariasi
tergantung
pada
lingkungan dan fungsi yang disediakan. Padahal
tersebut terdapat biaya pemeliharaan tahunan yang juga
dimasukan dalam daftar harga DBMS.
4. Biaya penambahan perangkat keras
Kebutuhan tempat penyimpanan bagi DBMS
dan database sangat membutuhkan pembelian tempat
penyimpanan tambahan lebih lanjut untuk mencapai
performa yang diperlukan, dan akan membutuhkan
spesifikasi perangkat keras yang lebih muktahir dan
sebagainya yang memerlukan biaya yang tidak sedikit.
Tergantung pada spesifikasi perangkat keras yang
diperlukan.
5. Biaya konversi
Di dalam situasi tertentu, biaya DBMS dan
hardware tambahan mungkin relatif kecil biayanya
dibandingkan dengan biaya mengkonversi aplikasi
yang ada untuk berjalan di DBMS baru dan perangkat
keras. Biaya ini juga termasuk biaya pelatihan
karyawan untuk menggunakan sistem baru, dan
mungkin kerja dengan karyawan spesialis untuk
membantu dengan konversi dan menjalankan sistem.
Biaya ini merupakan salah satu alasan utama mengapa
beberapa organisasi merasa terikat pada sistem mereka
saat ini. dan tidak bisa beralih ke teknologi database
yang lebih modern.
20
21
6. Kinerja
Kinerja DBMS secara umum sangat baik.
Namun, DBMS ditulis lebih umum, untuk melayani
banyak aplikasi bukan hanya satu. Hasilnya adalah
bahwa beberapa aplikasi mungkin berjalan secepat
dulu. Dan biasanya, sistem file-based ditulis untuk
aplikasi tertentu seperti faktur.
7. Dampak kegagalan lebih besar
Sumber daya terpusat akan meningkatkan
kerentanan sistem. Karena semua pengguna dan
aplikasi bergantung pada ketersediaan DBMS, sehingga
apabila terjadi kegagalan komponen tertentu dapat
membawa operasi berhenti.
22
2.1.4 Database Life Cycle
Gambar 2.1 Database Lifecycle (Connolly dan Begg, 2010:314)
2.1.4.1 Database Planning
Menurut Connolly dan Begg (2010:313), Database
Planning adalah kegiatan manajemen yang memungkinkan
tahapan siklus hidup sistem database untuk direalisasikan
seefisien dan seefektif mungkin.
2.1.4.2 System Definition
23
Menurut Connolly dan Begg (2010:316), System
Definition
mendefinisikan
perspektif
sistem
database
berdasarkan ruang lingkup dan batasan dari aplikasi dan user
views.
2.1.4.3 Requirement Collection and Analysis
Menurut
Requirement
Connolly
Collection
dan
and
Begg
Analysis
(2010:316-320),
adalahh
proses
pengumpulan dan analisis informasi tentang bagian dari
organisasi yang akan didukung oleh sistem database, dan
menggunakan informasi ini untuk mengidentifikasi persyaratan
untuk sistem baru.
2.1.4.4 Database Design
Menurut Connolly dan Begg (2010:320-325), Database
Design adalah proses pembuatan desain yang akan mendukung
mission statement dan mission objectives perusahaan untuk
sistem database yang dibutuhkan.
2.1.4.5 DBMS (Database Management System) Selection
Menurut Connolly dan Begg (2010:325-329), DBMS
Selection adalah proses pemilihan DBMS yang tepat untuk
mendukung sistem database.
2.1.4.6 Application Design
Menurut
Connolly
dan
Begg
(2010:329-333),
Application Design adalah desain user interface dan program
aplikasi yang menggunakan dan memproses database.
2.1.4.7 Prototyping
Menurut Connolly dan Begg (2010:333), Prototyping
adalah proses pembuatan model kerja sementara untuk sistem
database. Umumnya sebuah prototype merupakan sebuah
24
model kerja yang tidak memiliki semua fitur atau memberikan
semua fungsi dari sistem.
2.1.4.8 Implementation
Menurut
Connolly
dan
Begg
(2010:333-334),
Implementasi adalah realisasi fisik dari database dan desain
aplikasi.
Implementasi database
dapat
dicapai dengan
menggunakan Data Definition Language (DDL) dari DBMS
yang dipilih.
2.1.4.9 Data Conversion and Loading
Menurut Connolly dan
Begg (2010:334),
Data
Conversion and Loading adalah proses pemindahan beberapa
data yang sudah ada ke dalam database baru dan mengubah
aplikasi yang sudah ada untuk dapat dijalankan pada database
yang baru.
2.1.4.10 Testing
Menurut Connolly dan Begg (2010:334-335), Testing
adalah proses untuk menjalankan program aplikasi dengan
maksud
menemukan
dan
mencari
kesalahan-kesalahan.
Sebelum digunakan, aplikasi database yang baru seharusnya
telah melalui tahap percobaan.
2.1.4.11 Operational Maintenance
Menurut
Connolly
dan
Begg
(2010:335-336),
Operational Maintenance adalah sebuah proses pemantauan
dan pemeliharaan terhadap sistem setelah di instalasi.
2.1.5 Metodologi Perancangan Database
Menurut Connolly dan Begg (2010:466), terdapat tiga fase
utama dalam metodologi perancangan basis data antara lain:
2.1.5.1 Perancangan Basis Data Konseptual
25
Perancangan basis data konseptual merupakan langkah
pertama yang dilakukan dalam merancang sistem basis data.
Pada langkah ini difokuskan pada pemodelan data konseptual
perusahaan yang sama sekali tidak bergantung pada detil-detil
implementasi. Perancangan basis data konseptual ini bertujuan
untuk membangun model data konseptual dari kebutuhan data
dari perusahaan. Model data konseptual terdiri dari: tipe
entitas, tipe relasi, atribut dan domain atribut, primary key dan
alternate key, dan batasan integritas. Model data konseptual
juga didukung oleh dokumentasi, termasuk ER diagram dan
kamus data yang dihasilkan melalui pengembangan model data
konseptual. Seperti yang disampaikan oleh Woldemichael dan
Hashim (2011:253), bahwa desain konseptual adalah proses
pengetahuan intensif yang memerlukan beragam pengetahuan.
Dengan demikian, permodelan harus mencakup sarana untuk
menyimpan dan mengambil pengetahuan desain untuk
meningkatkan
pengetahuan
mendesain.
Proses
desain
konseptual dapat dianggap sebagai spesifikasi transformasi
desain, yang diberikan sebagai persyaratan menjadi satu atau
lebih konsep yang dapat memenuhi persyaratan untuk
pengembangan lebih lanjut.
Langkah- langkah yang dijalankan pada tahap ini:
1. Mengidentifikasi tipe entitas
Pertama-tama
dilakukan
pengidentifikasian
entitas dengan melihat objek-objek yang digunakan
oleh user. Tujuannya adalah untuk mengidentifikasi
entitas yang diperlukan.
2. Mengidentifikasi tipe relasi
Tujuan identifikasi tipe relasi ini adalah untuk
mengetahui relasi penting yang ada antara entitasentitas.
Pada
tahap
ini,
relasi
digambarkan
menggunakan ER Diagram untuk mempermudah
dalam melihat relasi.
26
3. Mengidetifikasikan dan menghubungkan atribu-atribut
dengan entitas atau relasi
Pada langkah ini, ditentukan tipe-tipe fakta
mengenai entitas dan relasi yang akan di masukkan ke
dalam basis data. Tujuan langkah ini adalah untuk
menghubungkan atribut-atribut dengan entitas atau
relasi yang sesuai.
4. Menentukan atribut domain
Menurut Connolly dan Begg (2010:477-478),
Domain adalah sebuah kumpulan nilai-nilai dari satu
atau lebih atribut yang diambil nilainya. Tujuan dari
langkah ini adalah untuk menentukan domain untuk
atribut-atribut pada model data konseptual.
5. Menentukan atribut candidate key, primary key, dan
alternate key
Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi candidate key untuk setiap entitas dan,
jika ada lebih dari satu candidate key, maka akan
dipilih satu dari antara semua candidate key tersebut
untuk menjadi primary key sementara sisanya menjadi
alternate key.
6. Mempertimbangkan penggunaan konsep enhanced
modeling (optional)
Tujuan
langkah
ini
adalah
untuk
mempertimbangkan penggunaan enhanced modeling,
seperti spezialitation/generalization, aggregation, dan
composition.
7. Melakukan pengecekan redudansi pada model
Pada
tahap
ini,
tujuannya
adalah
untuk
melakukan pemeriksaan model data konseptual untuk
menidentifikasi
adanya
redudansi
dan
menghilangkannya.
8. Menvalidasi model data konseptual terhadap transaksi
user
27
Tujuan langkah ini adalah untuk memastikan
bahwa model data konseptual yang dibuat mendukung
kebutuhan transaksi. Untuk memastikan model data
konseptual mendukung kebutuhan transaksi, ada dua
pendekatan yang dapat digunakan:
• Mendeskripsikan transaksi
• Menggunakan transaction pathways
2.1.5.2 Perancangan Basis Data Logikal
Tujuan utama dari perancangan basis data logikal ini
adalah untuk menerjemahkan model data konseptual ke dalam
model data logikal yang kemudian divalidasi untuk memeriksa
benar tidaknya model data logikal secara struktural dan
kemampuannya untuk mendukung kebutuhan transaksi.
Langkah-langkah yang dijalankan pada tahap ini:
1. Mengambil relasi untuk model data logikal
Tujuan dari langkah ini adalah untuk membuat
relasi
untuk
model
data
logikal
untuk
mempresentasikan entitas, relasi, dan atribut yang telah
di identifikasi. Dalam mendeskripsikan relasi yang
diambil, berikut relasi yang mungkin terjadi:
• Tipe entitas kuat
Menurut
Connolly
dan
Begg
(2010:492), Entitas kuat adalah entitas yang
keberadaannya
tidak
bergantung
pada
keberadaan entitas lainnya. Dimana pada
entitas ini mempunyai karakter bahwa setiap
kejadian entitas teridentifikasi secara unik
yang memiliki atribut primary key yang dapat
membedakan dari entitas yang lain.
• Tipe entitas lemah
Menurut
Connolly
dan
Begg
(2010:492-493), Sedangkan tipe entitas lemah
28
merupakan
entitas
yang
keberadaanya
tergantung oleh beberapa entitas yang lain.
Pada entitas ini, karakteristik yang dimilikinya
ialah setiap kejadian entitas tidak dapat
teridentifikasi secara unik hanya dengan
menggunakan atribut entitas tersebut, tidak
seperti
halnya
tipe
entitas
kuat
yang
menggunakan primary key.
• One-to-many (1:*) tipe relasi binary
Menurut
Connolly
dan
Begg
(2010:493), Kondisi ini terjadi apabila tiap
anggota pada entitas pertama mempunyai
pasangan dengan lebih dari satu anggota
entitas kedua.
• One-to-one (1:1) tipe relasi binary
Menurut
Connolly
dan
Begg
(2010:493-495), Pada tipe relasi ini dapat
terjadi apabila tiap anggota pada entitas Client
hanya dapat berpasangan dengan satu anggota
dari entitas Preference. Demikian sebaliknya
tiap entitas Preference juga hanya dapat
berpasangan dengan satu anggota dari entitas
Client.
•
One-to-one (1:1) tipe relasi rekursif
•
Superclass/subclass relationship types
•
Many-to-many (*:*) tipe relasi binary
Pada hubungan antar entitas ini akan
terjadi apabila kedua anggota entitas tersebut
dapat berpasangan lebih dari satu anggota
entitas.
•
Tipe relasi yang komplek
Relasi yang komplek adalah jumlah
dari suatu kejadian yang mungkin dari suatu
29
entitas dalam n-ary relationship ketika nilai
entitas yang lain (n-1) diketahui.
• Atribut multi-valued
2. Validasi relasi menggunakan normalisasi
Tujuan langkah ini adalah untuk melakukan
validasi model data logikal menggunakan normalisasi.
Tujuan dari normalisasi ini adalah untuk memastikan
set dari relasi mempunyai sejumlah atribut yang
minimal
namun
cukup
yang
diperlukan
untuk
mendukung kebutuhan data perusahaan.
3.
Validasi relasi terhadap transaksi user
Tujuan langkah ini adalah untuk memastikan
relasi model data logikal yang dibuat mendukung
kebutuhan
transaksi,
secara
detil
seperti
yang
dispesifikasikan pada kebutuhan user.
4.
Mendefinisikan batasan integritas
Tujuan langkah ini adalah untuk memeriksa
apakah batasan integritas ditampilkan dalam model
data logikal. Batasan integritas ini bertujuan untuk
melindungi basis data dari ketidak lengkapan, ketidak
akuratan, atau ketidak konsistenan. Berikut adalah
beberapa tipe batasan integritas:
• Required data
Beberapa atribut harus memiliki isi pada
datanya
sehingga
tidak
diperbolehkan
menerima null.
• Attribute domain constraints
Masing-masing atribut memiliki domain yang
merupakan sekumpulan nilai yang sah.
• Multiplicity
• Entity integrity
Dimana primary key dari sebuah entitas tidak
dapat bernilai null.
30
• Referential integrity
Bila foreign key mempunyai nilai, maka nilai
tersebut haruslah menunjuk pada tuple yang
ada pada relasi induk. Untuk melakukan itu,
referential
integrity
existence
constraints
perlu
dispesifikasikan
yang
mendefinisikan
kondisi dimana sebuah candidate key atau
foreign key ditambahkan, diubah, atau di hapus.
Jika terdapat sebuah tuple dari relasi induk
dihapus, maka referential integrity akan hilang
apabila adanya tuple anak menunjuk ke tuple
induk yang dihapus.
Ada beberapa cara yang dapat digunakan:
a. No Action
Strategi
yang
digunakan
ialah
mencegah
penghapusan dari relasi induk jika terdapat
refrensi ke tuple anak.
b. Cascade
Apabila pada tuple induk dihapus, maka secara
otomatis tuple anak akan dihapus juga.
c. Set Null
Jika pada tuple induk dihapus, maka nilai
foreign key pada semua tuple anak otomatis
akan terisi nilai null.
d. Set Default
Jika pada tuple induk dihapus, maka foreign
key pada semua tuple akan menerima nilai
default.
e. No Check
Jika tuple induk dihapus, maka tidak dilakukan
apapun untuk meyakinkan bahwa referential
integrity terjaga.
5.
Melakukan review model data logikal dengan user
31
Tujuan langkah ini adalah untuk melakukan
review
bersama
user
untuk
memastikan
user
mempertimbangkan model yang telah dibuat sesuai
dengan kebutuhan data perusahaan.
6.
Menggabungkan model data logikal menjadi model
global (optional)
Tujuan
dari
langkah
ini
adalah
untuk
menggabungkan model data logikal menjadi data
logikal global tunggal yang menampilkan semua user
views dari basis data.
7. Melakukan pemeriksaan untuk perkembangan di masa
datang
Tujuan langkah ini adalah untuk menentukan
apakah ada perubahan yang signifikan di masa
mendatang dan untuk menilai apakah model data
logikal dapat mengakomodasi perubahan-perubahan
tersebut.
2.1.5.3 Perancangan Basis Data Fisikal
Dalam proses perancangan basis data fisikal, akan
dihasilkan deskripsi implementasi dari basis data pada
secondary storage. Perancangan basis data fisikal akan
mendeskripsikan basis relasi, file organisasi dan index yang
digunakan untuk mencapai akses data yang efisien dan segala
batasan integritas yang terkait dan masalah sekuritas.
Langkah-langkah yang dijalankan pada tahap ini:
1. Menerjemahkan model data logikal untuk target
DBMS
Tujuan langkah ini adalah untuk menghasilkan
skema relasi basis data dari model data logikal yang
dapat diimplementasikan pada target DBMS. Untuk
menjalankan tahap ini, terbagi menjadi tiga langkah
sebagai berikut.
• Merancang relasi dasar (base relation)
32
Pada langkah ini, hal pertama yang
dilakukan
adalah
pengumpulan
dan
pemahaman informasi tentang relasi yang
telah dihasilkan selama perancangan logikal
basis data. Setelah itu, menentukan bagaimana
mempresentasikan relasi dasar pada target
DBMS. Setiap relasi yang diidentifikasikan
dalam model data logikal memiliki definisi
yang terdiri dari: nama relasi, daftar atribut
sederhana, primary key, alternate keys, dan
foreign keys, dan referensial integritas batasan
untuk setiap foreign keys yang diidentifikasi.
• Merancang representasi dari data yang diambil
Tujuan
menentukan
langkah
ini adalah
bagaimana
untuk
mempresentasikan
data yang diambil dari data yang ada di dalam
model data logikal pada target DBMS.
• Merancang batasan umum
Tujuan
langkah
ini adalah
untuk
merancang batasan umum untuk target DBMS.
2. Merancang file organisasi dan index
Tujuan langkah ini adalah untuk menentukan
file organisasi yang optimal untuk menyimpan relasi
dasar dan index yang diperlukan untuk mencapai
kinerja yang sesuai, yaitu bagaimana jalan dari relasi
dan tuple dapat disimpan dalam secondary storage.
Tahap ini dibagi menjadi empat langkah, yaitu:
• Menganalisa transaksi
Tujuan
langkah
ini adalah
untuk
memahami transaksi secara fungsional yang
akan dijalankan dalam basis data dan untuk
menganalisa transaksi yang penting. Untuk
membantu mengidentifikasi transaksi mana
yang
perlu
diteliti,
dapat
menggunakan
33
transaction relation cross-reference matrix
yang
menunjukkan
relasi
setiap
akses
tranasaksi. Untuk fokus pada area yang
mungkin bermasalah, salah satu cara untuk
melanjutkan:
a. Map seluruh jalan transaksi untuk relasi.
b. Tentukan relasi mana yang sering
diakses oleh transaksi.
c. Analisa penggunaan data dari transaksi
yang dipilih yang melibatkan transaksitransaksi lain.
• Memilih file organisasi
Tujuan
langkah
ini adalah
untuk
menentukan organisasi file yang efisien untuk
setiap relasi dasar.
• Memilih index
Tujuan
langkah
ini adalah
untuk
menentukan apakah penambahan index akan
meningkatkan kinerja dari sistem.
• Memperkirakan kapasitas disk yang diperlukan
Tujuan
langkah
ini adalah
untuk
memperkirakan jumlah kapasitas disk yang
akan diperlukan oleh basis data sehingga dapat
diperkirakan penggunaan kapasitas disk setiap
tahunnya.
3. Merancang user views
Tujuan langkah ini adalah untuk merancang
user views yang diidentifikasi selama pengumpulan
kebutuhan dan analisa tahap dari pengembangan
siklus kehidupan sistem basis data.
4. Merancang mekanisme security
Tujuan langkah ini adalah untuk merancang
mekanisme security untuk basis data seperti yang
telah
dispesifikasikan
oleh
user
selama
tahap
34
pengumpulan
dan
analisa
kebutuhan
dari
pengembangan siklus kehidupan sistem basis data.
2.1.6 ERD (Entity-Relationship Diagram)
Menurut Whitten dan Bentley (2007:271), ERD (Entity
Relationship Diagram) adalah model data yang menggunakan
beberapa notasi untuk menggambarkan data dalam konteks entitas dan
hubungan yang dideskripsikan oleh data tersebut. ERD digunakan
untuk memodelkan struktur data dan hubungan antar data. Dengan
ERD, model dapat diuji dengan mengabaikan proses yang dilakukan.
Tabel 2.1 Tabel Notasi dalam ERD (Whitten dan Bentley, 2007:273)
Notasi
Keterangan
Entitas adalah suatu objek yang dapat di identifikasi
dalam lingkungan pemakai.
Relasi menunjukkan adanya hubungan di antara
sejumlah entitas yang berbeda.
Atribut berfungsi mendeskripsikan karakter entitas
(atribut yang berfungsi sebagai key diberi garis
bawah).
Garis sebagai penghubung antara relasi dengan
entitas, relasi, dan entitas dengan atribut.
2.1.7 Kardinalitas Relasi
35
Menurut Whitten dan Bentley (2007:276), dalam ERD
hubungan (relasi) dapat terdiri dari sejumlah entitas yang disebut
dengan derajat relasi. Derajat relasi maksimum disebut dengan
kardinalitas sedangkan derajat minimum disebut dengan modalitas.
Jadi kardinalitas relasi menunjukkan jumlah maksimum entitas yang
dapat berelasi dengan entitas pada himpunan entitas lain.
a.
One to One Relationship
Hubungan antara file pertama dan file kedua adalah satu
berbanding satu.
Contoh:
Pada pengajaran private satu guru satu siswa.
“Seorang guru mengajar seorang siswa, seorang siswa diajar
oleh seorang guru”.
Gambar 2.2 Entitas One to One Relationship
b.
One to Many atau Many to One Relationship
Hubungan antara file pertama dan file kedua adalah satu
berbanding banyak atau banyak berbanding satu.
Contoh:
Dalam suatu perusahan satu bagian mempekerjakan banyak
pegawai.
“Satu bagian mempekerjakan banyak pegawai, satu pegawai
kerja dalam satu bagian”.
Gambar 2.3 Entitas Many to One Relationship
c.
Many to Many Relationship
Hubungan file pertama dan file kedua adalah banyak
berbanding banyak.
36
Contoh:
Dalam universitas seorang mahasiswa dapat mengambil
banyak mata kuliah.
“Satu mahasiswa mengambil banyak matakulih dan satu
matakuliah diambil banyak mahasiswa.”
Gambar 2.4 Entitas Many to Many Relationship
2.1.8 Langkah-Langkah Perancangan Teknik Entity-Relationship
Menurut Connolly dan Begg (2010:364), sumber awal data
teknik perencanaan database dengan ER adalah data dictionary
(kumpulan data). Langkah-langkah perancangan ER:
1.
Memilih kelompok atribut yang sama untuk dijadikan sebuah
entitas dan menentukan primary key dengan syarat unik dan
mewakili entitas.
2.
Menggambarkan Cardinality dari ER diagram berdasarkan
analisa relasi yang didapat. Relasi yang terjadi dapat one to
one, one to manY dan many to many relationship.
3.
Membentuk Skema Database atau LRS (Logical Record
Structure) berdasarkan ER diagram.
Keterangan:
•
Bila relasi one to one maka foreign key diletakkan pada salah
satu dari dua entitas yang ada atau menyatukan ke dua entitas
tersebut.
•
Bila relasi one to many maka foreign key diletakkan di entitas
yang Many.
•
Bila relasi many to many maka dibuat “file konektor” yang
berisi 2 foreign key yang berasal dari kedua entitas.
•
Membentuk tabel-tabel berdasarkan primary key yang terpilih
dengan syarat sudah mencapai aturan normalisasi sekurangkurangnya 3NF dari Skema DB/LRS yang ada.
37
2.1.9 Normalisasi
Menurut Connolly dan Begg (2010:416-417), normalisasi
merupakan sebuah teknik untuk memproduksi satu set hubungan
dengan sifat yang diinginkan, memberikan kebutuhan data pada
perusahaan. Proses Normalisasi antara lain:
•
Suatu teknik formal untuk menganalisis relasi berdasarkan
primary key dan fungsi dependensi antar atribut yang ada.
•
Di eksekusi dalam beberapa cara. Setiap cara mengacu ke
bentuk normal tertentu, sesuai dengan sifat yang dimilikinya.
•
Setelah Normalisasi diproses, relasi akan secara bertahap lebih
terbatas/kuat bentuk formatnya dan juga mengurangi tindakan
anomali pada setiap update.
Bentuk-bentuk normalisasi menurut Connolly dan Begg
(2010:428-455), antara lain:
1. Unnormalized Form (UNF)
Merupakan
sebuah
tabel
awal
yang
belum
ternormalisasi yang berisikan satu atau lebih kumpulan data
yang berulang. Untuk membuat tabel UNF yaitu dengan
memindahkan data dari sumber informasi yang di dapat ke
dalam tabel dengan format baris dan kolom, jika ada atribut
yang mempunyai banyak nilai (multivalue) akan masuk ke
dalam bentuk UNF.
2. First Normal Form (1NF)
Bentuk normalisasi tahap pertama yang merupakan
sebuah relasi dimana sebuah titik pertemuan antara setiap baris
dan kolom yang berisi satu dan hanya satu nilai.
3. Second Normal Form (2NF)
Tahapan kedua setelah 1NF terpenuhi yaitu 2NF
dimana merupakan sebuah relasi yang terdapat di dalam 1NF
dan setiap atribut yang bukan primary key bergantung pada
primary key.
4. Third Normal Form (3NF)
38
Merupakan tahapan ketiga dalam normalisasi dimana
sebuah relasi yang terdapat pada bentuk normalisasi pertama
dan kedua, yang mana atribut primary key bergantung pada
primary key.
2.1.10 Teori Waterfall
Gambar 2.5 Fase-Fase Model Teori Waterfall (Pressman, 2010:39)
1. Communication
Langkah ini merupakan analisis terhadap kebutuhan
software, dan tahap untuk mengadakan pengumpulan data
dengan melakukan pertemuan dengan customer, maupun
mengumpulkan data-data tambahan baik yang ada di jurnal,
artikel, maupun dari internet.
2. Planning
Proses planning merupakan lanjutan dari proses
communication (analysis requirement). Tahapan ini akan
menghasilkan dokumen user requirement atau bisa dikatakan
sebagai data yang berhubungan dengan keinginan user dalam
pembuatan software, termasuk rencana yang akan dilakukan.
3. Modeling
Proses modeling ini akan menerjemahkan syarat
kebutuhan ke sebuah perancangan software yang dapat
diperkirakan sebelum dibuat coding. Proses ini berfokus pada
rancangan struktur data, arsitektur software, representasi
interface, dan detail (algoritma) prosedural. Tahapan ini akan
menghasilkan dokumen yang disebut software requirement.
4. Construction
39
Construction merupakan proses membuat kode.
Coding atau pengkodean merupakan penerjemahan desain
dalam bahasa yang bisa dikenali oleh komputer. Programmer
akan menerjemahkan transaksi yang diminta oleh user.
Tahapan inilah yang merupakan tahapan secara nyata dalam
mengerjakan suatu software, artinya penggunaan komputer
akan dimaksimalkan dalam tahapan ini. Setelah pengkodean
selesai maka akan dilakukan testing terhadap sistem yang
telah dibuat tadi. Tujuan testing adalah menemukan
kesalahan-kesalahan
terhadap
sistem
tersebut
untuk
kemudian bisa diperbaiki.
5. Deployment
Tahapan ini bisa dikatakan final dalam pembuatan
sebuah software atau sistem. Setelah melakukan analisis,
desain dan pengkodean maka sistem yang sudah jadi akan
digunakan oleh user. Kemudian software yang telah dibuat
harus dilakukan pemeliharaan secara berkala.
2.1.11 Tools yang digunakan
2.1.11.1 UML (Unified Modelling Language)
Menurut Whitten & Bentley (2007:371), UML
(Unified Modelling Language) adalah suatu metode yang
digunakan untuk menentukan dan menggambarkan sistem
piranti lunak dari segi objek orientasinya. UML tidak
menentukan metode untuk mengembangkan sistem, tetapi
hanya membuat notasi yang sekarang dikenal secara luas dan
diakui sebagai standar untuk pemodelan objek.
2.1.11.1.1 Diagram Use Case
Menurut Sommerville (2011:124), diagram Use
Case merupakan sebuah diagram yang menunjukkan
interaksi antara sistem dan lingkungan. Setiap diagram
40
use case merepresentasikan tugas yang berlainan yang
melibatkan hubungan antara lingkungan dengan sistem.
Dalam
bentuk
yang
paling
sederhana,
kasus
penggunaan ditunjukkan sebagai elips dengan aktor.
Menurut Whitten dan Bentley (2007:382),
diagram Use Case menggambarkan fungsi sistem dari
perspektif pengguna dengan cara dan terminologi
mereka mengerti. Untuk akurat dan benar-benar
mencapai hal ini, use case menuntut tingkat tinggi
keterlibatan pengguna dan ahli subjek-materi yang
memiliki pengetahuan tentang proses bisnis atau acara.
Diagram Use Case dekat kaitannya dengan
kejadian-kejadian. Kejadian (scenario) merupakan
contoh apa yang terjadi ketika seseorang berinteraksi
dengan sistem.
41
Tabel 2.2 Tabel Simbol pada Diagram Use Case (Whitten dan Bentley, 2007:246248)
No
Gambar
Nama
Fungsi
Simbol
1
Aktor
Aktor adalah segala sesuatu yang berinteraksi
dengan sistem untuk melakukan pertukaran
informasi.Aktor umumnya mempresentasikan
interaksi antara manusia dengan sistem dimana
aktor merupakan manusia tetapi dapat juga
digunakan untuk merepresentasikan perangkat
eksternal.
2
Use Case
Use case digunakan untuk menjelaskan fungsi
dari sistem yang merepresentasikan tujuan dari
sistem dan mendeskripsikan aktivitas dan
interaksi user dengan sistem untuk mencapai
tujuan tersebut.
3
Hubungan
Menggambarkan hubungan antara dua simbol
pada use case diagram,misalnya hubungan antara
aktor dengan use case.
4
Sistem
Sistem ialah tempat untuk menaruh setiap kerja
yang dilakukan dan menjadi tempat terjadinya
seluruh aktivitas.
42
Gambar 2.6 Diagram Use Case Hubungan Aktor dengan Kejadian
(Whitten dan Bentley, 2007:246)
2.1.11.1.2 Diagram Class
Menurut Sommerville (2011:129), diagram
class digunakan pada saat perancangan model sistem
yang berorientasi objek untuk menunjukkan kelas objek
yang ada di dalam sistem dan hubungan dari kelaskelas yang ada. Diagram class pada UML dapat di
implementasikan pada beberapa gambaran yang detail.
Ketika perancangan suatu model, tahap awal ialah
melihat pada dunia asli, kemudian menentukan objekobjek yang dianggap penting dan mempresentasikannya
sebagai suatu kelas. Ketika menggambarkan hubungan
antar kelas maka perlu diberikan penjelasan yang jelas
di setiap kelasnya.
Menurut Whitten dan Bentley (2007:382),
diagram class menggambarkan struktur dari suatu
objek sistem yang menunjukkan bahwa sistem ini
43
terdiri atas hubungan antar kelas objek. Berikut ini
merupakan penjelasan tentang tabel asosiasi diagram
class.
Tabel 2.3 Tabel Asosiasi Diagram Class (Whitten dan Bentley, 2007:377)
44
Gambar 2.7 Diagram Class Produk (Whitten dan Bentley, 2007:404)
2.1.11.1.3 Diagram Activity
Menurut
Whitten
&
Bentley
(2007:382),
diagram activity menggambarkan urutan aliran kegiatan
kasus atau prosesbisnis. Diagram activity juga dapat
digunakan
untuk
model
logika
dengan
sistem.
Dalam diagram activity terdapat beberapa simbol yang
digunakan untuk menerangkan proses dalam sistem,
yaitu:
45
Tabel 2.4 Tabel Simbol pada Diagram Activity (Whitten dan Bentley, 2007:391)
No
Gambar
Nama Simbol
1
Initial Node
2
Actions
Deskripsi
Menunjukkan awal dari suatu proses.
Menunjukkan
langkah-langkah
aktivitas sistem yang terjadi
3
Flow
Untuk
menunjuk
ke
aksi atau
proses yang lain dan dilengkapi
dengan
kata-kata
jika
berasal
dari decision.
4
Decision
Memiliki sebuah flow masuk dan dua
atau lebih flow keluar. Menunjukkan
aktivitas yang dapat dipilih.
5
Merge
Menyatukan flow yang
sebelumnya
terpisah oleh decision.
6
Fork
Menotasikan permulaan aksi atau
proses paralel yang dapat terjadi
dalam suatu urutan atau terjadi secara
bersamaan.
7
Join
Semua aksi yang masuk ke join harus
telah diselesaikan
sebelum
proses
berlanjut.
8
Activity Final
Menunjukkan akhir dari suatu proses
46
Gambar 2.8 Diagram Activity Melakukan Input Member Baru (Whitten dan Bentley,
2007:392)
2.1.11.2 STD (State Transition Diagram)
47
State Transition Diagram (STD) adalah diagram yang
digunakan untuk menggambarkan suatu proses dihubungkan
antara satu dengan yang lain dalam waktu yang bersamaan.
STD terdiri dari notasi state dan transition state. Masingmasing notasi terdiri atas kejadian (sistem) dan aksi (user).
•
Keadaan
•
Perubahan keadaan
2.1.11.3 DFD (Data Flow Diagram)
Menurut Jogiyanto Hartono (2005:701), DFD (Data
Flow Diagram) adalah diagram yang menggunakan notasi
simbol untuk menggambarkan arus data sistem. DFD sering
digunakan untuk menggambarkan suatu sistem yang telah ada
atau sistem yang baru yang akan dikembangkan secara logika
dan menjelaskan arus data dari mulai pemasukan sampai
dengan keluaran data tingkatan diagram arus data mulai dari
diagram konteks yang menjelaskan secara umum suatu sistem
atau batasan sistem dari level 0 dikembangkan menjadi level 1
sampai sistem tergambarkan secara rinci. Gambaran ini tidak
tergantung pada perangkat keras, perangkat lunak, struktur
data atau organisasi file.
1. Kesatuan Luar (External Entity)
Kesatuan luar (external entity) merupakan
kesatuan (entity) di lingkungan luar sistem yang dapat
berupa orang, organisasi, atau sistem lain yang berada
pada lingkungan luarnya yang memberikan input atau
menerima output dari sistem.
48
2. Arus Data (Data Flow)
Kesatuan luar (external entity) merupakan
kesatuan (entity) di lingkungan luar sistem yang dapat
berupa orang, organisasi, atau sistem lain yang berada
pada lingkungan luarnya yang memberikan input atau
menerima output dari sistem.
3. Proses (Process)
Proses (process) menunjukan pada bagian
yang
mengubah
input
menjadi
output,
yaitu
menunjukan bagaimana satu atau lebih input diubah
menjadi beberapa output. Setiap proses mempunyai
nama, nama dari proses ini menunjukan apa yang
dikerjakan proses.
4. Simpanan Data (Data Store)
Data Store merupakan simpanan dari data yang
dapat berupa suatu file atau database pada sistem
komputer.
Istilah data flow diagram bertingkat (leveled
DFD) digunakan untuk menggambarkan hirarki dari
berbagai
diagram,
yang
digunakan
untuk
mendokumentasikan suatu sistem.
a. Diagram Nol (Zero)
Diagram Nol (Zero) adalah diagram tingkat
menengah yang menggambarkan proses-proses utama
49
dalam sistem, yang terdiri dari sistem, hubungan entity,
proses, data flow dan data store.
b. Diagram Konteks
Diagram Konteks adalah diagram yang terdiri
dari proses dan menggambarkan hubungan terminator
dengan sistem yang mewakili suatu proses.
2.1.11.4 Delapan Golden Rules
Menurut
Shneiderman
(2010:88-89),
dalam
merancang antarmuka pengguna (interaksi manusia dan
komputer) membutuhkan 8 prinsip yang diaplikasikan hampir
di semua sistem interaktif dan biasanya disebut Golden Rules.
Berikut adalah kedelapan Golden Rules tersebut:
1. Berusaha
untuk
tetap
konsisten
(strive
for
consistency)
Konsistensi harus dilakukan pada setiap
urutan tindakan, perintah, menu, layar bantuan,
penggunaan
warna,
kapitalisasi,
fonts,
dan
sebagainya kecuali pada tampilan untuk konfirmasi
erintah menghapus.
2. Menyediakan penggunaan secara universal (cater to
universal usability)
Menyediakan fitur untuk pemula, juga
menyediakan fitur seperti tombol cepat (shortcut)
untuk pengguna expert agar mempermudah dan
mempercepat
aksi,
selain
itu
juga
untuk
meningkatkan kualitas sistem.
3. Memberikan umpan balik yang informatif (offer
informative feedback)
Suatu sistem umpan balik (feedback) harus
diperhitungkan untuk setiap tindakan dari pengguna.
Untuk tindakan yang sering dilakukan dan tidak
terlalu penting, cukup diberi umpan balik yang
50
sederhana saja. Namun jika sebaliknya, maka umpan
balik yang diberikan sebaiknya lebih substansial.
4. Merancang dialog pada keadaan akhir (design
dialogs to yields closure)
Urutan tindakan harus disusun kedalam suatu
kelompok dengan bagian awal, tengah, dan akhir.
Suatu umpan balik yang informatif sebaiknya dibuat
pada akhir tindakan untuk memberikan indikasi
bahwa cara yang dilakukan sudah benar atau
tindakan tersebut telah selesai dan siap untuk
melanjutkan ke tindakan berikutnya.
5. Memberikan pencegahan dan penanganan kesalahan
yang sederhana (prevent errors)
Sistem
yang
dibuat
diharapkan
tidak
menghasilkan kesalahan yang serius saat digunakan
oleh pengguna. Jika pengguna melakukan kesalahan,
sistem harus dapat mendeteksi kesalahan pengguna
dan menawarkan solusi sederhana serta instruksi
yang spesifik untuk melakukan recovery.
6. Memungkinkan
pembalikan aksi yang mudah
(permit easy reversal of actions)
Diharapkan adanya fitur untuk kembali
(back) ke aktivitas sebelumnya. Hal ini dapat
mengurangi kekuatiran pengguna karena pengguna
mengetahui kesalahan yang telah dilakukan dapat
dibatalkan, sehingga mendorong pengguna untuk
mengeksplorasi pilihan-pilihan lain yang belum
biasa digunakan.
7. Mendukung pusat kendali internal (support internat
locus of control)
Pada
berpengalaman
umumnya,
pengguna
yang
memiliki
keinginan
untuk
mengendalikan antarmuka sistem secara penuh,
maka sepatutnya sistem harus dapat merespon
51
tindakan yang dilakukan pengguna dengan baik.
Sebaiknya
sistem
dirancang
sedemikian
rupa
sehingga pengguna menjadi inisiator daripada
responden.
8. Mengurangi beban ingatan jangka pendek (reduce
short-term memory load)
Karena keterbatasan ingatan manusia untuk
memproses informasi dalam jangka pendek, maka
harus
dihindari
keadaan
dimana
pengguna
diharuskan mengingat suatu informasi di suatu layar
dan diharuskan menggunakan informasi tersebut di
layar yang berbeda serta diberikan cukup waktu
untuk mempelajari kode, mnemonic, dan urutan
tindakan.
2.1.11.5 PHP (Hypertext Prepocessor)
Menurut
Anhar
(2010:3),
PHP
(Hypertext
Prepocessor) adalah bahasa server-side scripting yang
menyatu dengan HTML untuk membuat halaman web yang
dinamis. Dinamis berarti halaman yang akan ditampilkan
dibuat saat halaman itu diminta oleh client. Mekanisme ini
menyebabkan informasi yang diterima client selalu yang
terbaru. Semua script PHP diesksekusi pada server dimana
script tersebut dijalankan.
2.1.11.6 MySQL (Structured Query Language)
Menurut Anhar (2010:45), MySQL (My structure
Query Language) adalah salah satu database management
system (DBMS) dari sekian banyak DBMS seperti Oracle,
MS SQL, postagre SQL, dan lainnya. My SQL berfungsi
untuk mengolah data base menggunakan bahasa SQL.
MySQL
bersifat
open
source
sehingga
kita
bisa
menggunakanya secara gratis. Pemrograman PHP juga sangat
mendukung/support dengan database MySQL.
52
2.2 Teori yang Berkaitan dengan Tema
2.2.1 Pembelian
Pembelian didefinisikan sebagai usaha untuk memenuhi
kebutuhan atas barang atau jasa yang diperlukan oleh perusahaan dan
dapat diterima tepat pada waktunya dengan mutu yang sesuai serta
harga yang menguntungkan.
a. Saat pemesanan
Saat pemesanan sangatlah tergantung pada kualitas barang
yang masih ada, rata-rata tingkat pemakaiannya dan jangka waktu
pemesanan.
b. Jumlah yang dipesan
Jumlah yang dipesan ditetapkan secara matematis dan juga
menurut kebijaksanaan untuk medapatkan kuantitas pesanan-pesanan
ekonomis.
c. Rekanan
Dalam menetapkan pilihan rekanan mesti dikaitkan pada
harga, syarat pembayaran, kualitas keandalan lokasi saat penyerahan
yang dijanjikan.
Menurut Mulyadi (2010:299), pembelian adalah suatu usaha
yang dilakukan untuk pengadaan barang yang diperlukan oleh
perusahaan.
Jenis pembelian berdasarkan pemasok:
1. Pembelian lokal adalah pembelian dari pemasok yang berasal
dari dalam negeri.
2. Pembelian impor adalah pembelian dari pemasok yang berasal
dari luar negeri.
Jenis pembelian berdasarkan transaksi:
1. Transaksi
pembelian
tunai
adalah
jenis
transaksi
dimana pembayarannya dilakukan secara langsung pada saat
barang diterima.
2. Transaksi
pembelian
kredit
adalah
jenis
transaksi
dimana pembayarannya tidak dilakukan secara langsung pada
53
saat barang diterima, tetapi dilakukan selang beberapa waktu
setelah barang diterima, sesuai perjanjian kedua belah pihak.
Menurut Mulyadi (2010:299), fungsi yang terkait dalam sistem
akuntansi pembelian adalah:
1. Fungsi gudang
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. Untuk barang-barang yang langsung dipakai (tidak
diselenggarakan persediaan barang di gudang), permintaan pembelian
diajukan oleh pemakai barang.
2. Fungsi pembelian
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
Fungsi penerimaan bertanggungjawab untuk melakukan
pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima
pemasok bertujuan untuk menentukan dapat atau tidaknya barang
tersebut diterima oleh perusahaan. Fungsi ini juga bertanggungjawab
untuk menerima barang dari pembeli yang berasal dari transaksi retur
penjualan.
4. Fungsi akuntansi
Fungsi akuntansi yang terkait dalam transaksi pembelian
adalah fungsi pencatat hutang dan fungsi pencatat persediaan.
Fungsi pencatat hutang bertanggungjawab 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
pencatat
persediaan
54
bertanggung jawab untuk mencatat harga pokok persediaan barang
yang dibeli ke dalam kartu persediaan.
Menurut Mulyadi (2010:301), 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 dan 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 mengenai order pembelian
yang telah dikeluarkan oleh perusahaan.
4. Prosedur penerimaan barang
Dalam prosedur ini, fungsi penerimaan barang 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.
5. Prosedur distribusi pembelian
Prosedur ini meliputi distribusi rekening yang di debit dari
transaksi
pembelian
manajemen.
untuk
kepentingan
pembuatan
laporan
55
Retur Pembelian
Menurut
Mulyadi
(2010:335),
sistem
retur
pembelian
digunakan dalam perusahaan untuk pengembalian barang yang sudah
dibeli kepada pemasoknya. Barang yang sudah diterima pemasok
terkadang tidak sesuai dengan barang yang dipesan menurut surat
order pembelian. Ketidaksesuaian itu terjadi kemungkinan karena
barang yang diterima tidak cocok dengan spesifikasi yang tercantum
dalam surat order pembelian, barang mengalami kerusakan dalam
pengiriman, atau barang yang diterima melewati tanggal pengiriman
yang dijanjikan oleh pemasok. Fungsi terkait dalam sistem retur
pembelian adalah:
1. Fungsi gudang
Fungsi gudang bertanggung jawab untuk menyerahkan barang
kepada fungsi pengiriman seperti yang tercantum dalam tembusan
memo debit yang diterima dari fungsi pembelian.
2. Fungsi pembelian
Fungsi pembelian bertanggung jawab untuk mengeluarkan
memo debit untuk retur pembelian.
3. Fungsi pengiriman
Fungsi pengiriman bertanggung jawab untuk mengirimkan
kembali barang kepada pemasok sesuai dengan perintah retur
pembelian dalam memo debit yang diterima dari fungsi pembelian.
4. Fungsi akuntansi
Fungsi akuntansi bertanggung jawab untuk mencatat transaksi
retur pembelian dalam jurnal retur pembelian atau jurnal umum,
mencatat berkurangnya harga pokok persediaan karena retur
pembelian dalam kartu persediaan, dan mencatat berkurangnya hutang
yang timbul dari transaksi retur pembelian dalam arsip bukti kas
keluar yang belum dibayar atau dalam kartu hutang.
Menurut Mulyadi (2010:339), sistem retur pembelian terdiri
dari jaringan prosedur berikut ini:
1. Prosedur perintah retur pembelian
56
Dalam prosedur ini, retur pembelian terjadi atas perintah
fungsi pembelian kepada fungsi pengiriman untuk mengirimkan
kembali barang yang telah diterima oleh fungsi penerimaan kepada
pemasok yang bersangkutan. Dokumen yang digunakan oleh fungsi
pembelian untuk memerintahkan fungsi pengiriman mengembalikan
barang ke pemasok adalah memo debit.
2. Prosedur pengiriman barang ke pemasok
Dalam prosedur ini, fungsi pengiriman barang kepada pemasok
sesuai dengan perintah retur pembelian yang tercantum dalam memo
debit dan membuat laporan pengiriman barang untuk transaksi retur
pembelian tersebut.
3. Prosedur pencatatan hutang
Dalam prosedur ini, fungsi akuntansi memeriksa dokumendokumen
yang
berhubungan
dengan
retur
pembelian
dan
menyelenggarakan pencatatan berkurangnya hutang dalam kartu
hutang atau mengarsipkan dokumen memo debit sebagai pengurang
hutang.
2.2.2 Penjualan
Penjualan merupakan kegiatan yang dilakukan oleh penjual
dalam menjual barang atau jasa dengan harapan akan memperoleh
laba dari adanya transaksi-transaksi tersebut dan penjualan dapat
diartikan sebagai pengalihan atau pemindahan hak kepemilikan atas
barang atau jasa dari pihak penjual ke pembeli.
Secara umum penjualan pada dasarnya terdiri dari dua jenis
yaitu penjualan tunai dan kredit. Penjualan tunai terjadi apabila
penyerahan barang atau jasa segera diikuti dengan pembayaran dari
pembelian, sedangkan penjualan kredit ada tenggang waktu antara
saat penyerahan barang atau jasa dalam penerimaan pembelian.
Keuntungan dari penjualan tunai adalah hasil dari penjualan
tersebut langsung terealisir dalam bentuk kas yang dibutuhkan
perusahaan untuk mempertahankan likuiditasnya. Sedangkan dalam
rangka memperbesar volume penjualan, umumnya perusahaan
menjual produknya secara kredit. Penjualan kredit tidak segera
57
menghasilkan pendapatan kas, tapi kemudian menimbulkan piutang.
Kerugian dari penjualan kredit adalah timbulnya biaya administrasi
piutang dan kerugian akibat piutang tak tertagih.
Perancangan Sistem Informasi Akuntansi Penjualan
Beberapa fungsi yang terkait dalam prosedur penjualan adalah
sebagai berikut:
1. Fungsi Kas
Fungsi ini bertanggungjawab sebagai penerima kas dari
pembeli.
2. Fungsi Gudang
Fungsi gudang berfungsi untuk menyediakan barang yang
diperlukan oleh pelanggan sesuai dengan yang tercantum dalam
tembusan faktur penjualan yang diterima dari fungsi penjualan.
3. Fungsi Akuntansi
Fungsi ini bertanggungjawab sebagai pencatat transaksi
penjualan dan penerimaan kas dan pembuatan laporan penjualan.
2.2.3 Persediaan Barang
Barang dagangan dalam perusahaan disebut dengan persediaan
barang dagangan atau kadang-kadang disingkat pesediaan. Adapun
definisi persediaan barang dagangan menurut Mulyadi (2010:553)
adalah barang yang dibeli untuk tujuan dijual kembali dapat
disimpulkan bahwa barang dagangan merupakan barang-barang yang
disediakan dengan tujuan untuk dijual kembali kepada para konsumen
dan digunakan untuk mencatat harga pokok barang dagang selama
periode normal kegiatan perusahaan.
Dalam sistem akuntasi pembelian manajemen memerlukan
informasi mengenai data – data yang diperlukan untuk mengambil
keputusan yang tepat dalam menjalankan kegiatan pembelian.
Beberapa informasi yang diperlukan oleh manajemen dari sistem
akuntansi pembelian adalah sebagai berikut:
1. Jenis persedian yang telah mencapai titik pemesanan kembali
(reorder point).
58
Yaitu untuk mengetahui jumlah jenis persediaan barang
dagangan yang harus dipesan kembali, agar saat jenis
persediaan dibutuhkan, barang dagangan tersebut tersedia
dalam gudang.
2. Pesanan pembelian yang telah dikirim kepada pemasok
Yaitu untuk mengetahui jumlah pesanan pembelian dan
pemasok mana yang dipilih dalam pesanan pembelian
3. Pesanan pembelian yang telah dipenuhi oleh pemasok
Yaitu untuk mengetahui jumlah ketersediaan pemasok dalam
memenuhi pesanan pembelian
4. Total saldo utang dagang pada tanggal tertentu
Yaitu untuk mengetahui total saldo utang dagang perusahaan
dan mengetahui tanggal jatuh tempo pembayaran utang dagang
yang harus dibayar perusahaan.
5. Saldo utang dagang pada pemasok tertentu
Yaitu untuk mengetahui rincian saldo utang dagang dari
masing-masing pemasok dan mengetahui tanggal jatuh tempo
pembayaran kepada pemasok tersebut.
6. Tambahan kuantitas dan harga pokok persediaan dari
pembelian.
Download