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