bab 2 landasan teori fix -...
TRANSCRIPT
7
BAB 2
LANDASAN TEORI
2.1 Teori-teori Umum
2.1.1 Teknologi Informasi dan Basis Data
Menurut Whitten (2004, p8), Teknologi Informasi adalah suatu
istilah kontemporer yang mendeskripsikan kombinasi dari teknologi
computer (perangkat keras dan piranti lunak) dengan teknologi
telekomunkasi (data, gambaran, dan suara).
Data adalah fakta, atau bagian dari fakta yang mengandung arti, yang
dihubungkan dengan kenyataan, simbol-simbol, gambar-gambar, kata-kata,
angka-angka, huruf-huruf, atau simbol-simbol yang menunjukkan suatu ide,
objek, kondisi, atau situasi dan lain – lain. Data adalah representasi objek
yang disimpan dan kejadian-kejadian yang memiliki maksud dan penting
bagi user (Hoffer, 2005, p5).
Basis Data (database) adalah kumpulan data yang terhubung satu
sama lain secara logikal, dan deskripsi data itu dirancang untuk memenuhi
kebutuhan informasi dari sebuah organisasi. Basis data digunakan sebagai
tempat penyimpanan data yang secara simultan digunakan oleh banyak
departemen dan pengguna. Semua data terintegrasi dengan jumlah duplikasi
yang minimum. Basis data ini tidak hanya dipunyai oleh satu departemen
8
saja tetapi di-share oleh beberapa sumber lainnya (Connolly, 2005, p15),
sedangkan menurut Date, 2000, p10, basis data adalah kumpulan data-data
yang digunakan oleh sistem aplikasi dari perusahaan.
Basis data adalah kumpulan data-data yang disimpan dalam suatu
format yang telah distandarisasi, dirancang untuk dibagikan kepada banyak
user (Post, 2005, p2).
2.1.2 Database Management System
Database Management System (DBMS) adalah sebuah sistem
software yang memperbolehkan pengguna untuk menggambarkan,
membuat, menjaga, dan mengontrol akses ke basis data (Connolly, 2005,
p16).
Menurut Silberschatz, 2002, p1, DBMS adalah suatu kumpulan data
yang terinterelasi dan seperangkat program untuk mengakses data-data yang
terinterlasi dan seperangkat program untuk mengakses data-data tersebut.
Fasilitas yang disediakan DBMS antara lain (Connolly, 2005, p16):
1. Memperbolehkan pengguna untuk menggambarkan basis data, melalui
Data Definition Language (DDL). DDL memberikan fasilitas kepada
pengguna untuk menspesifikasikan tipe data dan struktur serta constrain
pada data yang akan disimpan pada basis data.
9
2. Memperbolehkan pengguna untuk memasukkan, merubah, menghapus,
dan mengambil data dari basis data yang menggunakan Data
Manipulation Language (DML).
3. Menyediakan control akses ke basis data:
a. Sistem keamanan (security system), bertujuan mencegah pengguna
yang tidak mempunyai hak akses agar tidak mengakses basis data.
b. Sistem integritas (integrity system), bertujuan menjaga konsistensi data
yang disimpan.
c. Sistem kontrol pada saat yang bersamaan (concurrency control),
bertujuan memperbolehkan akses berbagi terhadap basis data.
d. Sistem control perbaikan (recovery control system), bertujuan
mengembalikan basis data ke kondisi sebelum yang konsistem pada
saat terjadi kegagalan pada perangkat keras dan perangkat lunak.
e. Katalog pengguna yang dapat diakses (user-accessible catalog), yang
berisi tentang deskripsi data pada basis data.
2.1.3 Database Application Lifecycle
Database application lifecycle adalah tahapan dalam
mengembangkan system aplikasi basisdata. Berikut adalah skema tahapan
basis data application lifecycle:
10
Gambar 2.1 Daur Hidup Aplikasi Basis Data
(Sumber: Connolly, 2005, p284)
11
Keterangan dari tiap tahapan dijelaskan sebagai berikut
(Connolly dan Begg, 2005, p273-p293):
A. Perencanaan Basisdata
Perencanaan basis data adalah aktivitas pengaturan yang
memungkinkan langkah-langkah aplikasi basis data lebih efisien dan
efektif. Perencanaan basis data harus terintegrasi dengan keseluruhan
strategi sistem informasi dari organisasi. Terdapat tiga hal pokok yang
bersangkutan dalam merumuskan strategi sistem informasi, yaitu:
1. Identifikasi rencana perusahaan dan tujuannya dengan
ketetapan selanjutnya dari kebutuhan sistem informasi
2. Evaluasi dari sistem informasi sekarang untuk menentukan
kelebihan dan kekurangan yang ada
3. Penilaian kesempatan teknologi informasi yang mungkin
dapat memegang keuntungan kompetitif
B. Definisi Sistem
Perencanaan basisdata adalah aktivitas pengaturan yang
memungkinkan langkah – langkah aplikasi basisdata lebih efisien dan
efektif. Perencanaan basisdata harus terintegrasi dengan keseluruhan
strategi sistem informasi dari organisasi. Terdapat tiga hal pokok yang
bersangkutan dalam merumuskan strategi sistem informasi, yaitu:
12
1. Identifikasi rencana perusahaan dan tujuannya dengan ketetapan
selanjutnya dari kebutuhan sistem informasi
2. Evaluasi dari sistem informasi sekarang untuk menentukan
kelebihan dan kekurangan yang ada
3. Penilaian kesempatan teknologi informasi yang mungkin dapat
memegang keuntungan kompetitif
Gambar 2.2 Representasi dari sebuah aplikasi basis data dengan banyak user
view : user view (1, 2, dan 3) dan (5 dan 6) mempunyai kebutuhan yang saling
melengkapi (seperti ditunjukkan dengan daerah yang diarsir), sementara user view 4
mempunyai kebutuhan yang berbeda
(Sumber : Connolly-Begg, 2005, p275)
13
C. Analisis dan Pengumpulan Kebutuhan Data
Proses mengumpulkan dan menganalisa informasi tentang
bagian dari organisasi yang nantinya akan didukung oleh aplikasi
basisdata, dan kemudian menggunakan informasi ini untuk mengetahui
kebutuhan pemakai terhadap sistem yang baru.
Pada tahap ini melibatkan kumpulan dan analisis infromasi
tentang bagian dari perusahaan yang akan dilayani oleh basisdata.
Informasi yang dikumpulkan untuk masing – masing sudut pandang
pemakai utama termasuk:
1. Deskripsi data yang digunakan atau dihasilkan
2. Keterangan data yang digunakan atau dihasilkan
3. Kebutuhan tambahan apapun untuk aplikasi basisdata yang
baru
Informasi ini kemudian dianalisa untuk diidentifikasi data –
data dan kebutuhannya untuk dimasukkan ke dalam aplikasi basisdata
yang baru.
D. Perancangan basisdata
Perancangan basisdata adalah proses membuat perancangan
untuk basisdata yang akan membantu operasi perusahaan dan
tujuannya.
14
Terdapat dua pendekatan utama dalam merancang suatu
basisdata, yaitu bottom-up dan top-down. Pendekatan bottom-up
dimulai pada tingkatan pokok (seperti, properti dari kesatuan dan
hubungan).
Strategi yang sesuai untuk rancangan basisdata yang lebih
kompleks dibutuhkan pendekatan top-down. Pendekatan ini dimulai
dengan pengembangan model data yang mengandung sedikit kesatuan
dan hubungan tingkat tinggi.
Sedangkan perancangan dibagi dalam tiga tahap yaitu
konseptual, logikal, dan fisikal.
E. Seleksi DBMS
Seleksi DBMS merupakan seleksi dari DBMS yang pantas
untuk menopang aplikasi basisdata. Bila tidak ada DBMS, maka bagian
dari daur kehidupan basisdata untuk membuat seleksi adalah antara
fase konseptual dan logikal basisdata. Akan tetapi, seleksi dapat
dilakukan sewaktu – waktu berhubung dengan perancangan logikal
menyediakan informasi yang ada cukup sesuai dengan kebutuhan
sistem seperti penampilan, kemudahan penyusunan, sekuritas, dan
batasan integritas.
Pada berikut ini adalah langkah – langkah utama dalam
penyeleksian DBMS:
15
1. Menetapkan syarat – syarat keterangan pembelajaran
2. Membuat daftar pendek dua atau tiga produk
3. Evaluasi produk
4. Rekomendasi seleksi dan hasil produksi
Dengan langkah terakhir pada seleksi DBMS ini untuk
mendokumentasikan proses dan menyediakan sebuah pernyataan dari
penemuan dan rekomendasi produk DBMS tertentu.
F. Perancangan aplikasi
Perancangan aplikasi yaitu rancangan dari tampilan layar
untuk pemakai dan aplikasi program yang menggunakan dan
memproses basisdata.
Hal ini melibatkan perancangan program aplikasi yang
mengakses basisdata dan membuat rancangan transaksi. Selain
merancang bagaimana cara untuk mencapai fungsionalitas yang
dibutuhkan, perlu juga merancang interface pemakai yang sesuai untuk
aplikasi basisdata.
G. Prototyping
Pembuatan model yang bekerja pada aplikasi basisdata ini
tidaklah secara umum mempunyai semua fitur – fitur yang diperlukan
atau menyediakan semua fungsi pada sistem final nantinya.
16
Tujuan utama dari pengembangan prototype aplikasi basisdata
adalah untuk memperbolehkan pemakai menggunakan prototype untuk
mengidentifikasi fitur – fitur sistem yang bekerja dengan baik, atau
tidak tercukupi.
H. Implementasi
Tahap yang merupakan realisasi fisikal dari basisdata dan
rancangan apliaksi. Setelah menyelesaikan tahapan perancangan,
barulah basisdata dan program aplikasi dapat diimplementasikan.
Implementasi basisdata dapat dicapai dengan menggunakan Data
Definition Language (DDL) dari DBMS yang dipilih atau sebuah
Graphical User Interface (GUI).
Aplikasi program yang digunakan diimplementasikan
menggunakan bahasa generasi ketiga atau keempat (3GL atau 4GL).
Sebagian dari program aplikasi ini adalah transaksi basisdata yang
diimplementasikan menggunakan Data Manipulation Language (DML)
dari DBMS yang dituju.
I. Konversi Data dan Loading
Pada tahap ini dilakukan perpindahan data yang telah ada ke
dalam basisdata yang baru dan mengubah aplikasi yang telah ada agar
dapat jalan pada basisdata yang baru.
Tahap ini diperlukan hanya ketika sistem basisdata yang baru
menggantikan sistem lama.
17
J. Testing
Testing adalah proses menjalankan program aplikasi dengan
tujuan untuk menemukan kesalahan atau kegagalan program.
Sebelum suatu aplikasi program basisdata dijalankan, perlu
diadakan pengujian. Bila pengujian berjalan dengan sukses, maka akan
menampakkan beberapa kegagalan yang ada pada program aplikasi dan
mungkin juga pada struktur basisdata. Tentunya pemakai sistem yang
baru ini harus ikut dilibatkan dalam proses pengujian.
K. Perawatan Operasional
Perawatan operasional adalah proses mengawasi dan
memelihara sistem berikut instalasinya. Pada tahap sebelumnya,
aplikasi basisdata telah diimplementasi dan diuji secara lengkap. Saat
ini sistem pindah ke tahap pemeliharaan, dimana melibatkan aktivitas
berikut :
1. Mengawasi pelaksanaan sistem. Bila pelaksanaannya
berada dibawah tingkat yang dapat diterima, maka perlu
mengorganisasikan kembali basisdata yang diperlukan.
2. Memelihara dan meningkatkan aplikasi basisdata ketika
dibutuhkan.
Ketika basisdata telah bekerja secara penuh, pengawasan
secara ketat diperlukan untuk memastikan pelaksanaan tetap berada
pada tingkat yang dapat diterima.
18
2.1.4 Normalisasi
Menurut Connolly 2005, p388, Normalisasi adalah sebuah teknik
untuk menghasilkan sekumpulan relai dengan properti yang diinginkan,
yang akan memberikan kebutuhan data bagi perusahaan. Relasi adalah
sebuah tabel dengan kolom dan baris. Tujuan normalisasi adalah sebagai
berikut:
1. Menghilangkan kumpulan relasi dari inserting, updating, dan delete
dependency yang tidak diharapkan
2. Mengurangi kebutuhan restrukturisasi kumpulan relasi dan
meningkatkan life spam program aplikasi
3. Membuat model relasional yang lebih informatif
Proses normalisasi menurut Connolly 2005, p401:
1. Unormalized Form(UNF)
Unormalized Form(UNF), yaitu sebuah tabel yang mengandung satu
atau lebih kelompok yang berulang.
2. First Normal Form (1NF)
First Normal Form (1NF) adalah sebuah relasi dimana persimpangan
dari setiap baris dan kolom yang mengandung satu dan hanya satu nilai
saja.
19
4. Second Normal Form (2NF)
Second Normal Form (2NF) adalah sebuah relasi dimana pada bentuk
normal pertama dan setiap attribute yang bukan Primary key adalah
kandidat key yang dipilih untuk mengidentifikasi tuple secara unik pada
sebuah relasi. Proses normalisasi 1NF ke 2NF dengan menghilangkan
partial dependencies. Jika terdapat partial dependencies, maka atribut
functionally dependent dari relasi akan dihilangkan dengan
menempatkannya pada sebuah relasi baru bersama dengan copy
determinant mereka.
Full functional dependency adalah suatu keadaan dimana jika A dan B
adalah atribut, B secara fungsional sangat tergantung pada A dan jika B
secara fungsional bergantung pada A, tetapi bukan subset dari A.
5. Third Normal Form (3NF)
Third Normal Form (3NF) adalah sebuah relasi dimana bentuk normal
pertama dan kedua, dan dimana tidak ada attribute yang bukan primary
key secara transitif bergantung pada primary key. Transitive
dependency adalah sebuah kondisi dimana A, B dan C adalah atribut
dari relasi dimana A → B dan B → C, maka C adalah transitive
dependency pada A melalui B.
20
6. Boyce-Codd Normal Form (BCNF)
Boyce-Codd Normal Form (BCNF) adalah sebuah relasi di dalam
BCNF, jika dan hanya jika, setiap determinan adalah candidate key.
2.1.5 Fourth GL (Generation Language)
Fourth GL merupakan non-procedural, dimana pengguna
menjelaskan apa yang perlu dilakukan dan bukan bagaimana yang perlu
dilakukan. Pengguna tidak perlu menjelaskan langkah-langkah program
yang harus dilakukan, tetapi hanya memberikan parameter untuk tool lalu
menggunakan tool tersebut untuk menghasilkan sebuah program aplikasi
(Connolly, 2002, p42). Bahasa generasi ke-empat meliputi :
1. Bahasa presentasi seperti query language dan report generators
2. Bahasa tertentu, seperti spreadsheet dan bahasa basis data
3. Bahasa aplikasi yang menjelaskan insert, update, dan mengambil
data dari basis data untuk membuat aplikasi.
4. Bahasa tingkat tinggi digunakan untuk menghasilkan kode aplikasi.
Salah satu contoh Fourth GL menurut Connolly (2005, p42)
adalah SQL (Structured Query Language). SQL adalah sebuah bahasa
yang dirancang menggunakan relasi untuk mengubah input kedalam output
yang diinginkan. SQL memiliki dua komponen utama yaitu: Data
21
Definition Language dan Data Manipulation Language Connolly, 2005,
p113).
A. Data Definition Language
Data Definition Language (DDL) adalah sebuah bahasa yang
memberikan fasilitas kepada DBA (Database Administrator) atau
pengguna untuk menjelaskan dan menamakan entity, attribute, dan
relationship yang dibutuhkan untuk aplikasi, bersama dengan
integritas yang berhubungan dan batasan-batasan keamanan. Database
Administrator adalah seseorang yang bertanggung jawab terhadap
realisasi fisikal basis data, termasuk rancangan fisik basis data dan
implementasi, keamanan dan kontrol integritas, maintanance sistem
operasional, dan memastikan kepuasan performance aplikasi kepada
user (Connolly, 2005, p40).
Data Definition Language (DDL) adalah perinta-perintah yang
digunakan untuk mendefinisikan sebuah database, termasuk membuat,
mengubah, dan menghapus tabel dan memberikan batasan-batasannya
(Hoffer, 2005, p291).
Data Definition Language (DDL) adalah sebuah bahasa yang
digunakan oleh DBMS untuk mendefenisikan sebuah database atau
pandangan dari sisi database (Whitten, 2004, p555).
22
B. Data Manipulation Language
Definisi dari Data Manipulation Language (DML) menurut
Connolly (2005,p41) adalah suatu bahasa yang memberikan fasilitas
pengoperasian data yang ada di dalam basis data. Pengoperasian data
yang akan dimanipulasi biasanya meliputi:
1. Perubahan data baru ke dalam basis data
2. Modifikasi data yang disimpan ke dalam basis data
3. Pengembalian data yang terdapat dalam basis data
4. Penghapusan data dari basis data
Sedangkan definisi procedural DML menurut Connolly (2002,
p41) adalah suatu bahasa yang memperbolehkan pemakai untuk
mendeskripsikan ke sistem data apa yang dibutuhkan dan bagaimana
mendapatkan data tersebut secara benar.
2.1.6 Tahap – tahap Perancangan Basis Data
2.1.6.1 Perancangan Konseptual
Perancangan basisdata konseptual merupakan tahapan
pertama dari perancangan basisdata dengan menggunakan informasi
yang diperoleh dari perusahaan dan juga merupakan proses
23
pembangunan model informasi yang digunakan oleh organisasi,
terbebas dari segala pertimbangan fisik (Connolly, 2005, p419).
Desain basisdata konseptual dimulai dengan pembuatan
model data konseptual perusahaan. Desain konseptual seluruhnya
independent dari implementasi seperti target DBMS, program
aplikasi, bahasa pemograman, perangkat keras, perfoma, dan
pertimbangan fisik lainnya. Model data konseptual didukung oleh
dokumentasi, termasuk kamus data, yang dihasilkan melalui
pembangunan model. Langkah-langkah untuk membuat model data
konseptual dapat digambarkan sebagai berikut:
1. Identify entity type, untuk menentukan entity utama yang
dibutuhkan, dengan kata lain membuat kelas-kelas dan obyek-
obyek yang ada.
2. Identify relationship type, untuk menentukan hubungan-
hubungan penting yang ada diantara jenis-jenis entity yang telah
diidentifikasi.
3. Identify and associate attributes with entity or relationship
types, untuk menentukan atribut yang berkaitan dengan entity
yang telah ditentukan.
4. Determine attribute domains, untuk menentukan domain untuk
tiap-tiap atribut yang ada dalam model data konseptual lokal.
24
5. Determine candidate and primary key attributes, untuk
mengidentifikasi candidate key dan primary key dari kumpulan
atribut pada tiap-tiap entity.
6. Consider user of enchanced modeling concepts (optional
step), untuk memikirkan kegunaan dari konsep model yang
telah dikembangkan.
7. Check model for redundancy, untuk memeriksa kelebihan
entity maupun atribut yang ada pada model tersebut.
8. Validate local conceptual model against user transactions,
untuk memastikan bahwa model konsep tersebut mendukung
proses transaksi yang dibutuhkan.
9. Review local conceptual data model with user, untuk mengkaji
ulang model konseptual yang telah kita buat dengan pemakai
sehingga para pemakai dapat memahami maksud basisdata yang
telah dibuat.
2.1.6.2 Perancangan Logikal
Perancangan logikal merupakan tahapan kedua dari
perancangan basisdata. Perancangan logikal adalah proses pembuatan
model informasi yang digunakan perusahaan berdasarkan spesifikasi
model data,tapi terbebas dari DBMS dan semua pertimbangan fisik
25
(Connolly, 2005, p441). Model data konseptual yang dibangun pada
fase sebelumnya diperluas dan dipetakan pada model data logikal.
Model data logikal merupakan sumber informasi untuk fase
selanjutnya, yang dinamakan physical design.
Terdapat dua tahapan dalam perancangan basisdata logikal,
yaitu pertama membangun model data logikal dan data konseptual
lokal. Tahap kedua mengkombinasikan model data logikal individual
kedalam sebuah model data logikal global tunggal yang
menggambarkan perusahaan.
Hasil akhir dari tahapan ini berupa kamus data yang beris i
semua atribut beserta key-nya (primary key, alternate key, dan foreign
key) dan ERD keseluruhan dengan semua atribut key-nya. Pada
tahapan inilah normalisasi dilakukan.
Langkah-langkah dalam metodologi perancangan logikal
basisdata yaitu:
Langkah 1: Membuat dan menvalidasi model logikal data
lokal untuk setiap bagian
Tujuan dari langkah ini adalah untuk membangun
suatu model logikal data lokal dari suatu model konseptual
data lokal yang merepresentasikan perusahaan dan kemudian
menvalidasi model ini untuk memastikan strukturnya benar
dan bahwa model tersebut mendukung transaksi yang diminta.
26
Langkah 1.1: Menghilangkan bagian yang tidak sesuai
dengan model relasi (langkah optional)
Tujuan dari langkah ini adalah untuk memperbaiki
model konseptual lokal data dengan menghilangkan feature-
feature yang tidak kompetibel dengan model relasi. Bagian
yang akan dibahas pada langkah ini antara lain :
1. Menghilangkan many-to-many (*.*) tipe relasi binary.
2. Menghilangkan many-to-many (*.*) tipe relasi rekursif.
3. Menghilangkan tipe relasi komplek
4. Menghilangkan multi value atribut
Langkah 1.2: Menganalisis relasi untuk model logical data
local
Tujuan dari langkah ini adalah untuk membuat suatu
relasi untuk model logikal data lokal yang merepresentasikan
suatu entiti, relasinya dan juga atribut yang telah
diidentifikasi. Adapun pendeskripsian bagaimana relasi dapat
diturunkan dari struktur data model yang ada sekarang, antara
lain :
1. Tipe entiti kuat
2. Tipe entiti lemah
27
3. One-to-many (1.*) tipe relasi binari
4. One-to-one (1.1) tipe relasi binari
5. One-to-one (1.1) relasi rekursif
6. Superclass atau subclass tipe relasi
7. Many-to-many tipe relasi binari
8. Tipe relasi komplek
9. Atribut multi value
Langkah 1.3: Menvalidasi relasi dengan normalisasi
Tujuan dari langkah ini adalah untuk menvalidasi
relasi dalam model logikal data lokal dengan menggunakan
teknik dari normalisasi. Tujuan dari normalisasi adalah
sebagai berikut :
a. Menghilangkan kumpulan relasi dari inserting,
updating dan delete dependensi yang tidak diharapkan.
b. Mengurangi kebutuhan restrukturisasi kumpulan relasi
dan meningkatkan life spam program aplikasi.
c. Membuat model relasional lebih informative.
Langkah 1.4: Menvalidasi relasi dengan transaksi user
28
Tujuan dari langkah ini adalah untuk memastikan
bahwa relasi di dalam model logikal data lokal mendukung
transaksi yang diminta user. Pada langkah ini, pengecekan
bahwa relasi yang dibuat di langkah sebelumnya juga
mendukung transaksi ini benar dan pastikan juga bahwa tidak
ada kesalahan dalam relasi yang telah dibuat.
Langkah 1.5: Memeriksa integritas database
Tujuan dari langkah ini adalah untuk mendefinisikan
ruang lingkup integritas yang diperlihatkan kepada pemakai.
Dalam hal ini ada 5 tipe ruang lingkup integritas, antara lain :
1. Data yang diminta
2. Domain pembatas atribut
3. Integritas entiti
4. Integritas referensi
Yang mendefinisikan suatu entiti mempunyai
integritas ialah tidak adanya primary key yang
kosong (null). Suatu primary key merupakan suatu
atribut yang mendefinisikan bahwa setiap record /
tuple itu unik satu sama lain.
5. Pembatas enterprise
29
Pembatas enterprise merupakan aturan tambahan
yang dibuat oleh pemakai atau seorang administrator
basisdata dari basisdata tersebut.
Langkah 1.6: Mereview model logikal data local dengan
user
Tujuan dari langkah ini adalah untuk membuat
dokumentasi yang mendeskripsikan model logikal data lokal
sebagai representasi yang sesuai dengan keadaan sebenarnya.
Hubungan antara Logikal Data Model dan Data Flow
Diagram
Suatu model logikal data merefleksikan struktur dari
dalam suatu enterprise. Sebuah data flow diagram (DFD)
menunjukan aliran data suatu enterprise dan disimpan di
dalam penyimpanan data. Semua atribut seharusnya berada di
dalam suatu tipe entiti. Jika memang ditangani di dalam
enterprise dan kemungkinan akan dilihat mengalir di sekitar
enterprise sebagai aliran data. Ada aturan yang mengontrol
antara dua teknik tersebut, antara lain:
1. Setiap penyimpanan seharusnya merepresentasikan suatu
tipe entity
30
2. Atribut dalam data flow seharusnya merupakan bagian dari
tipe entity
Langkah 2: Membangun dan menvalidasi model logikal
data global
Tujuan dari langkah ini adalah untuk mengkombinasi
suatu individual model logikal data lokal ke dalam suatu
model yang menggambarkan suatu enterprise.
Langkah 2.1: Menggabungkan model lokal logikal data
menjadi model global
Beberapa tugas dari pendekatan ini adalah sebagai berikut :
1. Me-review nama dan isi dari suatu entity atau relasi dan
candidate key.
2. Mereview nama dan isi dari suatu relasi dan foreign key.
3. Menggabungkan entity atau relasi dari model logical
data local.
4. Memasukkan (tanpa penggabungan) entity atau relasi
untuk setiap model lokal data.
31
5. Menggabungkan relasi atau foreign key dari model local
data.
6. Memasukkan (tanpa penggabungan) relasi atau foreign
key pada setiap model lokal data.
7. Mencek untuk entiti, relasi, dan foreign key yang hilang.
8. Mencek untuk foreign key.
9. Mencek untuk bahasa integritas.
10. Membuat global ERD atau relasi diagram.
11. Mengupdate dokumentasi.
Langkah 2.2: Menvalidasi model logikal data global
Tujuan dari langkah ini adalah untuk menvalidasi
relasi yang dibuat dari model logikal data global dengan
menggunakan teknik dari normalisasi dan juga memastikan
bahwa relasi yang dibuat mendukung transaksi.
Langkah 2.3: Mencek kemungkinan pengembangan di
masa depan
Tujuan dari langkah ini adalah untuk menentukan
bagian mana yang kelihatannya akan berubah ke masa
depannya dan juga memperhatikan supaya model logical data
global dapat mengakomodasi perubahan tersebut.
32
Langkah 2.4: Mereview model logikal data global dengan
user
Tujuan dari langkah ini adalah untuk memastikan
bahwa model logikal data global itu memang
merepresentasikan enterprise yang ada. Hasil akhir dari
perancangan logical database adalah merancang suatu model
informasi berdasarkan spesifik model yang ada (seperti model
relasional), tetapi tidak tergantung terhadap suatu DBMS dan
perangkat keras lainnya. Logikal basisdata merancang suatu
map untuk setiap lokal konseptual data. Jika terdapat lebih
dari satu pandangan pemakai, maka model logikal data lokal
akan dikombinasikan menjadi suatu model logikal data global
yang merepresentasikan semua pandangan user dari suatu
perusahaan.
2.1.6.3 Perancangan Fisikal
Tujuan dari langkah ini menurut Connolly (2005, p282)
adalah untuk mendeskripsikan pengimplementasian dari suatu
basisdata pada media penyimpanan secondary; itu juga akan
mendeskripsikan dasar dari suatu relasi, file organisasi, dan juga index
yang digunakan untuk mencapai suatu keefisienan data, integritas, serta
ukuran keamanan.
33
Langkah 1: Menerjemahkan model logikal data global
sesuai DBMS yang dipakai
Tujuan dari langkah ini adalah untuk membuat suatu
skema relasional basisdata dari model data logikal global yang
dapat diimplementasikan ke DBMS yang dipakai
Langkah 1.1: Merancang basis rasional
Tujuan dari bagian ini adalah untuk memutuskan
bagaimana merepresentasikn relasional dasar yang
diidentifikasi dalam model logikal data lokal pada DBMS
yang dipakai. Untuk memulai proses perancangan fisikal
basisdata, pertama-tama anda dapat mengumpulkan dan
meminimalisasikan suatu informasi tentang relational yang
dirancang selama perancangan logikal basisdata. Informasi
yang diperlukan bisa berasal dari kamus data dan definisi data
rasional yang didefinisikan menggunakan DDL. Untuk setiap
relasional yang diidentifikasi pada model data logikal global,
dapat diidentifikasikan salah satu basisdata :
1. Nama dari relational yang ada
2. Suatu list untuk atribut yang sederhana
3. Primary key, alternatife key, dan foreign key
34
4. Suatu daftar dari atribut turunan dan bagaimana
pembuatannya
5. Batasan integrasi untuk setiap foreign key yang
diidentifikasi
Dari kamus data, dari setiap atributnya dapat
diketahui :
1. Domain atribut tersebut yang terdiri dari tipe data,
panjang, dan berbagai keterangan atribut tersebut
2. Suatu optional nilai default untuk atribut
3. Apakah atribut dapat diisi nilai null
Langkah 1.2: Merancang representasi data turunan
Tujuan dari langkah ini adalah untuk memutuskan
bagaimana merepresentasikan suatu data turunan pada model
data logikal global pada DBMS yag dipakai. Atribut yang
nilainya didapatkan dengan mengevaluasi atribut lain dikenal
sebagai atribut turunan atau kalkulasi. Sebagai contoh :
1. Jumlah banyaknya staff yang bekerja pada suatu
kantor
2. Jumlah nasabah yang melakukan transaksi kredit
3. Jenis kredit yang diingini oleh nasabah
35
Langkah 1.3: Merancang batasan aplikasi
Tujuan dari langkah ini adalah untuk merancang
batasan aplikasi untuk DBMS yang dipakai. Mengupdate
suatu relasi yang mungkin dibatasi oleh aturan perusahaan
sesuai dengan transaksi yang sebenarnya bisa diupdate.
Perancangan batasan tersebut sekali lagi tergantung pada
DBMS yang digunakan, fasilitas yang dipunyai oleh system
dibandingkan dengan DBMS yang lain. Pada awalnya, jika
sistem tersebut mempunyai aturan sesuai aturan standar SQL,
beberapa batasan dapat diterapkan.
Langkah 2: Merancang representasi fisik
Tujuan dari langkah ini adalah untuk menentukan
organisasi file yg paling optimal untuk menyimpan relasional
dasar dan index yang diminta untuk performansi yang optimal
yang mana relational dan data yang ada disimpan pada
secondary storage.
Langkah 2.1: Menganalisis transaksi
Tujuan dari langkah ini adalah untuk mengerti fungsi
dari suatu transaksi dimana akan dijalankan pada basisdata
untuk menganalisis transaksi yang penting. Untuk membuat
perancangan fisikal basisdata yang efektif perlu untuk
mempunyai pengetahuan mengenai transaksi atau query yang
36
akan dijalankan di dalam basisdata. Ini termasuk kuantitatif
atau kualitatif informasi. Dalam menganalisis transaksi, dapat
diidentifikasikan kriteria performansi sebagai berikut :
1. Transaksi yang sering digunakan, dan akan
berdampakbesar terhadap performansi keseluruhan.
2. Transaksi yang merupakan transaksi bisnis yang
kritis.
3. Durasi waktu dalam harian atau mingguan yang akan
mendapatkan banyak permintaan pada basisdata.
Langkah 2.2: Memilih organisasi file
1. Tujuan dari langkah ini adalah untuk menentukan
organisasi file yang efektif untuk setiap relasional
data. Dalam banyak kasus yang ada, suatu relasional
DBMS akan memberikan sedikit bahkan tanpa
pilihan dalam memilih organisasi file, walaupun
beberapa akan mempunyai indeks yang spesifik.
Langkah 2.3: Memilih index
Tujuan dari langkah ini adalah untuk menentukan
penambahan indeks yang akan meningkatkan performansi dari
suatu sistem. Biasanya pemilihan suatu atribut untuk indeks
adalah sebagai berikut :
37
1. Suatu atribut yang digunakan paling sering untuk
operasi penggabungan, yang akan membuat
penggabungan itu lebih efektif.
2. Suatu atribut yang digunakan paling banyak untuk
mengakses suatu record di dalam relasi yang ada.
Langkah 2.4: Mengestimasi kapasitas penyimpanan yang
dibutuhkan
Tujuan dari langkah ini adalah untuk memperkirakan
ukuran kapasitas disk yang diperlukan untuk basisdata.
Langkah 3 : Merancang tampilan layar untuk user
Tujuan dari langkah ini adalah untuk merancang
tampilan pemakai yang diidentifikasi selama pengumpulan
informasi dan analisis dari siklus hidup aplikasi basisdata.
Langkah 4 : Merancang mekanisme keamanan
Tujuan dari langkah ini adalah untuk merancang
ukuran keamanan untuk basisdata yang telah dispesifikasikan
pemakai.Beberapa masalah keamanan yang perlu
diperhatikan:
1. Pencurian data (Theft and Fraud)
38
2. Kehilangan kerahasiaan suatu data (Loss of
Confidentially)
3. Kehilangan hak pribadi (Loss of Privacy)
4. Kehilangan integritas (Loss of integrity)
5. Kehilangan ketersediaan data (Loss of availability)
Hasil akhir perancangan fisikal basisdata adalah
suatu proses yang mendeskripsikan suatu implementasi dari
suatu database pada media penyimpanan. Ini mendeskripsikan
suatu relational dan struktur penyimpanan dan metodologi
pengaksesan data oleh pemakai yang efisien, selama batasan
integritas dan pengukuran keamanan.
2.1.2 ER Modeling
A. Tipe Entity
Tipe entity adalah sekumpulan objek yang memiliki properti yang
sama, yang diidentifikasikan di dalam organisasi karena keberadaannya
yang bebas (independent existence) (Connolly, 2005, p331). Sedangkan
entity occurrence adalah sebuah objek dari satu tipe entity yang dapat
diidentifikasi secara unik (Connolly, 2005, p333). Keberadaan objek –
objeknya secara fisik / nyata (physical exixtence), seperti entity Pegawai,
39
Rumah dan Pelanggan atau secara konseptual / abstrak (conceptual
existence), seperti entity Inspeksi, Penjualan dan Peninjauan.
Setiap tipe entity dilambangkan dengan sebuah persegi panjang
yang diberi nama dari entity tersebut. Nama tipe entity biasanya adalah
kata benda tunggal. Huruf pertama dari setiap kata pada nama tipe entity
ditulis dengan huruf besar. Representasi diagram tipe entity terlihat pada
gambar 2.3.
Gambar 2.3 Representasi diagram dari tipe entity Pegawai dan Cabang (Connolly,
2002, p333)
Tipe entiti dapat diklasifikasikan sebagai berikut:
1. Tipe Entity Kuat, yaitu tipe entity yang
keberadaannya tidak bergantung pada tipe entity
lainnya (Connolly, 2005, p342).
2. Tipe Entity Lemah, yaitu tipe entity yang
keberadaannya bergantung pada tipe entity lainnya
(Connolly, 2002, p343).
Nama entiti
Pegawai Cabang
40
Gambar 2.4 Representasi diagram tipe entity kuat dan tipe entity lemah (Connolly,
2005, p343)
B. Tipe Relasi
Tipe relationship adalah sekumpulan hubungan antar tipe
entityyang memiliki arti (Connlly, 2005, p334). Sedangkan relationship
occurrence adalah sebuah hubungan yang dapat diidentifikasikan secara
unik, yang meliputi sebuah kejadian (occurrence) dari setiap tiap entity di
dalam relationship (Connolly, 2005 p334).
Tipe relationship digambarkan dengan sebuah garis yang
menghubungankan tipe entity – tipe entity yang saling berhubungan. Garis
tersebut diberi nama sesuai dengan nama hubungannya dan diberi tanda
panah satu arah di samping nama hubungannya.
41
Biasanya sebuah relationship dinamakan dengan menggunakan
kata kerja, seperti Mengatur atau dengan sebuah frase singkat yang meliputi
sebuah kata kerja seperti DisewaOleh. Sedangkan tanda panah ditempatkan
di samping nama relationship yang mengindikasikan arah bagi pembaca
untuk mengartikan nama dari suatu relationship. Huruf pertama dari setiap
kata pada nama relationship ditulis dengan huruf besar. Representasi
diagram dari suatu tipe relationship terlihat pada gambar 2.4.
Gambar 2.5 Representasi diagram dari tipe relationship (Connolly, 2005, p335)
B.1 Derajat dari Tipe Relationship
Derajat dari tipe relationship adalah jumlah tipe entity yang
ikut serta dalam sebuah relationship (Connolly, 2005, p335).
Complex relationship types adalah sebuah relationship antara
tiga atau lebih tipe entity (Connolly, 2005, p445). Sebuah relationship
yang memiliki derajat dua di namakan binary (Connolly, 2005, p336).
Gambar 2.5 juga merepresentasikan diagram relationship derajat dua.
Sedangkan sebuah relationship derajat tiga dinamakan ternary, dan
Pegawai Cabang Memiliki
‘ Cabang Memiliki pegawai ‘
42
jika sebuah relationship memiliki derajat empat di namakan
quarternary (Connolly, 2005, p336).
Lambang belah ketupat merepresentasikan relationship yang
memiliki derajat lebih dari dua. Nama dari relationship tersebut
ditampilkan di dalam lambang belah ketupat. Panah yang biasanya
terdapat di samping nama suatu relationship dihilangkan.
Representasi diagram derajat tiga dari suatu tipe relationship terlihat
pada gambar 2.6.
Gambar 2.6 Representasi diagram derajat tiga dari suatu tipe relationship
(Connolly, 2005, p336)
B.2 Recursive Relationship
Recursive relationship adalah sebuah tipe relationship
dimana tipe entity yang sama ikut serta lebih dari sekali pada peran
yang berbeda (Connolly, 2005, p337).
Pegawai Cabang
Klien
Mendaftarkan
‘ Pegawai mendaftarkan seorang klien pada sebuah cabang ‘
43
Relationship dapat diberikan nama peran untuk menentukan
fungsi dari setiap entity yang terlibat dalam relationship tersebut.
Representasi diagram recursive relationship beserta nama perannya
terlihat pada gambar 2.7.
Nama peran juga dapat digunakan jika dua buah entity
dihubungkan melalui lebih dari satu relationship. Representasi
diagram nama peran yang digunakan pada dua buah entity terlihat
pada gambar 2.8.
Gambar 2.7 Representasi diagram recursive relationship dan nama peran
(Connolly, 2005, p337)
Pegawai
Pengawas
Nama peran
Mengawasi
Orang yang diawasi
Nama peran
‘ Pegawai (Pengawas) mengawasi pegawai (orang yang diawasi) ‘
44
Gambar 2.8 Representasi diagram entity dengan dua relationship berbeda beserta
nama peran (Connolly, 2005, p338)
C. Atribut
Atribut adalah properti sebuah entity atau relationship (Connolly,
2005, p338). Menurut Jeffery L. Whitten (2004, p295), atribut merupakan
properti deskriptif atau karakteristik dari sebuah entity. Atribut menampung
nilai yang menjelaskan setiap entity occurrence dan menggambarkan bagian
utama dari data yang disimpan di dalam basisdata.
Atribut domain adalah sekumpulan nilai yang dibolehkan bagi satu
atau lebih atribut (Connolly, 2005, p338). Atribut dapat diklasifikasikan
menjadi :
Pegawai Cabang
Nama peran
Nama peran
Manajer Kantor Cabang
Mengatur
Memiliki
Anggota Pegawai
Kantor Cabang
‘ Kantor cabang memiliki anggota pegawai ‘
45
1. Simple attribute adalah atribut yang terdiri dari komponen tunggal
dengan keberadaannya yang bebas (Connolly, 2005, p339).
2. Composit attribute adalah atribut yang terdiri dari beberapa komponen,
dan keberadaan setiap komponen tersebut bebas (Connolly, 2005, p339).
3. Single – valued attribute adalah atribut yang hanya memiliki sebuah nilai
untuk setiap occurrence dari sebuah entity (Connolly, 2005, p339).
4. Multi – valued attribute adalah sebuah atribut yang memiliki banyak nilai
untuk setiap occurrence dari sebuah tipe entity (Connolly, 2005, p340).
5. Derived attribute adalah atribut yang merepresentasikan sebuah nilai
yang diturunkan dari atribut lain yang berhubungan atau kumpulan dari
atribut (Connolly, 2005, p340).
D. Keys
Candidate key adalah himpunan atribut yang minimal yang secara
unik mengidentifikasikan setiap occurrence dari sebuah tipe entity
(Connolly, 2005, p340).
Composite key adalah sebuah candidate key yang terdiri atas dua
atau lebih atribut (Connolly, 2005, p341).
Primary key adalah candidate key yang terpilih untuk
mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entity
46
(Connolly, 2005, p341). Pada sebuah tipe entity biasanya terdapat lebih dari
satu candidate key yang salah satunya harus dipilih untuk menjadi primary
key. Pemilihan primary key didasarkan pada panjang atribut, jumlah
minimal atribut yang diperlukan dan keunikannya.
Alternate key adalah setiap candidate key yang tidak terpilih
menjadi primary key atau biasa disebut dengan secondary key (Whitten,
2004, p298).
Foreign key adalah sebuah primary key pada sebuah entity yang
digunakan pada entity lainnya untuk mengidentifikasikan sebuah
relationship (Whitten, 2004, p301).
Gambar 2.9 Representasi diagram entity Pegawai dan Cabang beserta atribut dan
primary keynya (Connolly, 2005, p342)
Memiliki
Primary key
Multi – valued
Derived attribut Composite
attribute
Pegawai
noPeg { PK } nama jabatan gaji /totalPeg
Cabang
noCab { PK }
alamat
jalan kota kodepos
telp[ 1..3]
Mengatur
Ruang untuk
menuliskan atribut
47
E. Structural Constraint
Batasan – batasan yang menggambarkan pembatasan pada
relationship seperti yang ada pada ‘ real world ‘ harus diterapkan pada tipe
entity yang ikut serta pada sebuah relationship. Jenis utama dari batasan
pada suatu relationship dinamakan multiplicity (Connolly, 2005, p344).
Multiplicity adalah jumlah occurrence yang mungkin terjadi pada
sebuah tipe entity yang berhubungan ke sebuah occurrence dari tipe entity
lain pada suatu relationship (Connolly, 2005, p344). Derajat yang biasanya
digunakan pada suatu relationship adalah binary relationship, yang terdiri
atas :
1. One – to – one ( 1 : 1 ) Relationship
Setiap relationship menggambarkan hubungan antara sebuah entity
occurrence pada entity yang satu dengan sebuah entity occurrence pada
entity lainnya yang ikut serta dalam relationship tersebut.
Pegawai tipe entiti ( noPeg )
Mengatur tipe relationship
Cabang tipe entiti ( noCab )
48
Gambar 2.10 Semantic net menunjukkan dua occurrence dari relationship Pegawai
mengatur Cabang ( Connolly, 2005, p345 )
Gambar 2.11 Multiplicity dari relationship one – to – one ( 1 : 1 ) ( Connolly, 2002, p346 )
2. One – to – many ( 1 : * ) Relationship
Setiap relationship menggambarkan hubungan antara sebuah entity
occurrence pada entity yang satu dengan satu atau lebih entity occurrence
pada entity lainnya yang ikut serta dalam relationship tersebut.
1..1 0..1 Pegawai
noPeg
Cabang
noCab
Multiplicity
Mengatur
Setiap cabang diatur oleh satu orang pegawai
Seorang pegawai dapat mengatur nol atau satu cabang
49
Gambar 2.12 Semantic net menunjukkan tiga occurrence dari relationship Pegawai
melihat RumahSewa ( Connolly, 2002, p346 )
Gambar 2.13 Multiplicity dan relationship one – to – many ( 1 : * ) (Connolly, 2002, p347)
3. Many – to – many ( * : * ) Relationship
Setiap relationship menggambarkan hubungan antara satu atau lebih
entity occurrence pada entity yang satu dengan satu atau lebih entity
Pegawai
noPeg
RumahSewa
noRumah 0..1 1..* Melihat
Setiap rumah sewa dilihat oleh nol
atau satu pegawai
Setiap pegawai melihat satu atau lebih rumah sewa
Pegawai tipe entiti ( noPeg )
Melihat tipe relationship
RumahSewa tipe entiti ( noRumah )
50
occurrence pada entity lainnya yang ikut serta dalam relationship
tersebut.
Gambar 2.14 Semantic net menunjukkan empat occurrence dari relationship Koran
mengiklankan RumahSewa ( Connolly, 2002, p348 )
Gambar 2.15 Multiplicity dari relationship many – to – many ( * : * ) (Connolly, 2002,
p348)
Koran
namaKoran
RumahSewa
noRumah 0..* 1..*
Mengiklankan
Setiap rumah sewa diiklankan pada nol atau lebih
Setiap koran mengiklankan satu atau lebih rumah
Koran tipe entiti
( )
Mengiklankan tipe relationship
RumahSewa tipe entiti ( noRumah )
51
2.2 Pembelian dan Penjualan
2.2.1 Pembelian
Pembelian artinya memperoleh barang dan jasa ( Render, 2001, p414).
Tujuan dari Pembelian, diantaranya :
1. Membantu mengidentifikasi produk dan jasa yang dapat diperoleh
secara eksternal.
2. Mengembangkan, mengevaluasi, dan menentukan pemasok, harga dan
pengiriman yang terbaik bagi barang dan jasa tersebut.
Strategi dalam Pembelian
Terdapat lima strategi dalam pembelian ( Render, 2001, p416),
yaitu:
1. Negosiasi dengan banyak pemasok dan membandingkan satu
pemasok dengan yang lainnnya, biasanya pesanan jatuh kepada
penawar yang termurah.
2. Mengembangkan hubungan jangka pendek, bersekutu dengan
beberapa pemasok yang akan bekerjasama dengan pembeli untuk
memuaskan konsumen akhir.
3. Interegasi vertikal. Maksud dari integrasi vertikal adalah
pengembangan kemampuan produksi barang atau jasa yang
sebelumnya atau dengan benar-benar membeli pemasok atau
52
distributor. Integrasi vertikal dapat mengambil bentuk integrasi
vertikal ke depan atau ke belakang. Yang dimaksud dengan
integrasi ke depan adalah mengusulkan perusahaan untuk
membuat barang jadi, sedangkan integrasi ke belakang justru
mengusulkan perusahaan pemasom membeli para pemasoknya.
4. Kombinasi beberapa pemasok dan integrasi vertikal, biasa
dikenal dengan ”keiretsu”.
5. Mengembangkan perusahaan-perusahaan maya yang
menggunakan pemasok dengan dasar ”pada saat dibutuhkan”.
Prosedur dalam Sistem Pembelian
Sistem pembelian dibentuk dari jaringan prosedur (
Mulyadi, 2001, p301), yaitu:
1. Prosedur permintaan pembelian
Dalam prosedur ini, fungsi gudang mengajikan permintaan
pembelian dalam formulir surat permintaan pembelian kepada
fungsi pembelian.
2. Prosedur permintaan penawaran harga dan pemilihan pemasok
Dalam prosedur ini, fungsi pembelian mengirimkan surat
permintaan penawaran harga kepada pemasok untuk memperoleh
informasi mengenai harga barang dan berbagai syarat pembelian
53
agar memungkinkan untuk memilih 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 organisasi yang lainnya dalam perusahaan mengenai
order pembelian yang sudah dikeluarkan oleh perusahaan.
4. Prosedur penerimaan barang
Dalam prosedur ini, fungsi penerimaan barang melakukan
pemeriksaan mengenai jenis, kuantitas, dan mutu bahan 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 dideber dari
transaksi pembelian untuk kepentingan pembuatan laporan
manajemen.
6. Prosedur pencatatan hutang
Dalam prosedur ini, fungsi akuntasi memeriksa dokumen-
dokumen yang berhubungan dengan pembelian ( surat oder
pembelian, laporan penerimaan barang, dan faktur dari pemasok )
dan menyelenggarakan pencatatan hutang atau mengarsipkan
dokumen sebagai catatan hutang.
54
Dokumen dalam Sistem Pembelian
Dokumen yang digunakan pada sistem pembelian (
Mulyadi, 2001, p303), adalah :
1. Surat permintaan pembelian
Formulir ini diisi oleh fungsi gudang atau fungsi pemakai barang
untuk meminta fungsi pembelian barang melakukan pembelian
barang dengan jenis, jumlah dan mutu seperti yang disebutkan
dalam surat tersebut. Biasanya terdiri dari dua lembar untuk setiap
permintaan, satu lembar untuk fungsi pembelian dan tembusannya
untuk arsip fungsi yang meminta barang.
2. Surat permintaan penawaran harga
Dokumen ini digunakan untuk meminta penawaran harga bagi
barang yang pengadaannya tidak bersifat berulangkali terjadi yang
menyangkut jumlah rupiah pembelian yang besar.
3. Surat order pembelian
Dokumen ini digunakan untuk memesan barang kepada pemasok
yang telah dipilih.
4. Laporan penerimaan barang
Dokumen ini dibuat oleh fungsi penerimaan untuk menunjukkan
bahwa barang yang diterima dari pemasok telah memenuhi jenis,
spesifikasi dan kuantitas seperti yang tercantum dalam surat order
pembelian.
55
5. Surat perubahan order pembelian
Digunakan bila terjadi perubahan terhadap isi surat order
pembelian yang sebelumnya telah diterbitkan. Perubahan tersebut
dapat berupa perubahan kuantitas, jadwal penyerahan barang,
spesifikasi, penggantian atau hal lain yang bersangkutan dengan
perubahan desain atau bisnis.
6. Bukti kas keluar
Dokumen ini dibuat oleh fungsi akutansi untuk dasar pencatatan
transaksi pembelian. Dokumen ini juga berfungsi sebagai perintah
pengeluaran kas untuk pembayaran hutang kepada pemasok dan
yang sekaligus berfungsi sebagai surat pemberitahuan kepada
kreditur mengenai maksud pembayaran.
2.2.2 Penjualan
Kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa,
baik secara kredit maupun secara tunai ( Mulyadi, 2001, p202).
Transaksi penjualan kredit terjadi jika order dari pelanggan telah
dipenuhi dengan pengiriman barang atau penyerahan jasa. Untuk jangka
waktu tertentu, perusahaan memiliki piutang kepada pelanggannya.
56
Transaksi penjualan tunai terjadi jika barang atau jasa baru
diserahkan oleh perusahaan kepada pembeli jika perusahaan telah menerima
kas dari pembeli.
2.2.2.1 Fungsi Penjualan
Fungsi-fungsi yang terkaitdengan sistem penjualan secara
kredit ( Mulyadi, 2001, p211) adalah :
1. Fungsi gudang
Fungsi ini bertanggung jawab untuk menyimnpan dan menyiapkan
barang yang dipesan oleh pelanggan dan mengirimkan barang
tersebut ke bagian pengiriman.
2. Fungsi penjualan
Fungsi ini bertanggung jawab untuk menerima surat order dari
pembeli, mengedit order dari pelanggan untuk menambahkan
informasi yang belum ada pada surat order tersebut, meminta
otorisasi kredit, menentukan tanggal pengiriman dari gudang mana
barang akan dikirim dan mengisi surat order pengiriman.
3. Fungsi pengiriman
Fungsi ini bertanggung jawab untuk menyerahkan barang ke
pelanggan berdasarkan surat order pengiriman yang diterima dari
fungsi penjualan.
4. Fungsi penagihan
57
Fungsi ini bertanggung jawab untuk membuat dan mengirimkan
faktur penjualan kepada pelanggan, serta menyediakan copy faktur
bagi kepentingan pencatatan transaksi penjualan oleh fungsi
akutansi.
5. Fungsi akutansi
Fungsi ini bertanggung jawab untuk mencatat piutang yang timbul
dari transaksi penjualan kredit dan membuat serta mengirimkan
pernyataan piutang kepada debitur, serta membuat laporan
penjualan.
2.2.2.2 Prosedur dalam Sistem Penjualan
Prosedur-prosedur yang membentuk sistem penjualan kredit
( Mulyadi, 2001, p219) adalah :
1. Prosedur order penjualan
Dalam prosedur ini, fungsi penjualan menerima order dari
pembeli dan menambahkan informasi penting pada surat order
dari pembeli. Kemudian fungsi penjualan membuat surat order
pengiriman dan mengirimkannya kepada bagian-bagian lain agar
memungkinkan fungsi tersebut untuk memberikan kontribusi
dalam melayani order dari pembeli.
2. Prosedur pengiriman
58
Fungsi pengiriman mengirimkan barang kepada pembeli sesuai
dengan informasi yang tercantum dalam surat order pengiriman
yang diterima dari fungsi pengiriman.
3. Prosedur distribusi penjualan
Mendistribusikan data penjualan menurut informasi yang
diperlukan kepada pihak manajemen.
4. Prosedur penagihan
Pada prosedur ini, fungsi penagihan membuat faktur penjualan
dan mengirimkannya kepada pembeli.
5. Prosedur persetujuan kredit
Pada prosedur ini, fungsi penjualan meminta persetujuan
penjualan secara kredit kepada pembeli tertentu dari fungsi kredit.
6. Prosedur pencatatan harga pokok penjualan
Pada prosedur ini, fungsi akutansi mencatat secara periodik total
harga pokok yang dijual dalam periode akutansi tertentu.
7. Prosedur pencatatan piutang
Pada prosedur ini, fungsi penagihan membuat faktur penjualan
dan mengirimkannya kepada pembeli.
59
2.2.2.3 Dokumen pada Sistem Penjualan
Dokumen-dokumen yang digunakan dalam sistem penjualan
kredit adalah sebagai berikut ( Mulyadi, 2001, p214) :
1. Surat order pengiriman dan tembusannya
2. Faktur dan tembusannya
3. Rekapitulasi harga pokok penjualan
4. Bukti Memorial
2.3 Bahasa Pemograman yang Digunakan
2.3.1 PHP Hypertext Preprocessor (PHP)
Dikutip dari Abdul Kadir ( 2002, pl ), PHP merupakan bahasa
berbentuk script yang ditempatkan dalam server dan diproses di server.
Hasilnya kemudian dikirim ke client, tempat pengguna menggunakan
browser. Secara khusus, PHP dirancang untuk membentuk web dinamis.
Artinya, ia dapat membentuk suatu tampilan berdasarkan permintaan
terkini. Misalnya, bisa menampilkan isi basis data ke halaman web. Pada
prinsipnya, PHP mempunyai funsi yang sama dengan script – script
seperti ASP ( Active Server Pages ), Cold Fusion, ataupun Perl.
60
2.3.2 MySql
MySQL merupakan salah satu jenis database server yang
menggunakan SQL sebagai bahasa dasar untuk mengakses basis datanya.
Bersifat bebas karena tidak perlu membayar untuk menggunakannya pada
berbagai platform (kecuali pada Windows yang bersifat shareware atau
perlu membayar setelah melakukan evaluasi dan memutuskan untuk
digunakan untuk keperluan produksi). MySQL termasuk jenis Relational
Database Management System (RDBMS) sehingga istilah seperti tabel,
baris, dan kolom digunakan.