9 BAB 2 LANDASAN TEORI 2.1. Teori Umum Basis Data (Database

BAB 2
LANDAS AN TEORI
2.1. Teori Umum
Basis Data (Database) sekarang merupakan bagian dari kehidupan kita
sehari-hari yang biasanya tidak kita sadari penggunaannya.
Basis data dapat
diartikan sebagai koleksi dari data yang berhubungan sementara sistem manajemen
basis data (Database Management System / DBM S) merupakan perangkat lunak
(software) yang mengatur dan mengontrol akses ke basis data. Aplikasi basis data
merupakan program yang berinteraksi dengan basis data pada beberapa titik dalam
eksekusinya. Istilah sistem basis data untuk memasukkan koleksi program aplikasi
yang berinteraksi dengan basis data.
Dalam sistem basis data, data diwakili dalam bentuk tabel-tabel yang saling
berhubungan satu sama lain berdasarkan nilai dari atribut tertentu yang sama. Data
yang saling berhubungan inilah yang merupakan inti dari basis data relasional.
Dalam basis data relasional, data didistribusikan ke dalam banyak tabel, namun
antara satu tabel dengan tabel lainnya memilki keterkaitan yang unik, sehingga
memungkinkan data dalam tabel tersebut disatukan kembali dan ditampilkan
sebagai satu kesatuan informasi yang dibutuhkan oleh pengguna basis data
tersebut.
9
10
2.1.1.
Pengertian Basis Data
M enurut Connolly (2005, p15), basis data adalah sebuah koleksi
logikal data yang saling terhubng satu sama lain dan gambaran dari data
tersebut dirancang untuk menemukan kebutuhan informasi pada suatu
organisasi / perusahaan. Sedangkan menurut Date (1999,p5), suatu sistem
basis data merupakan suatu sistem yang pada dasarnya menyimpan
record – record di dalam suatu sistem yang dilakukan secara
komputerisasi di mana tujuannya ialah membentuk suatu kumpulan data
yang terhubung dan DBM S / Sistem M anajemen Basis Data menjadi
program yang mengatur dan mengontrol akses ke basis data tersebut serta
memelihara informasi dan menjadikan informasi tersebut tersedia
berdasarkan permintaan.
M enurut Ramakrishnan (2003, p4), basis data adalah koleksi data,
secara tipikal menggambarkan aktivitas-aktivitas dari satu atau lebih
organisasi yang terkait. Pakar lain, Jeffery L. Whitten (2004, p548),
mengatakan bahwa basis data merupakan kumpulan dari file-file yang
saling berhubungan dimana setiap baris pada suatu basis data juga harus
saling terhubung dengan baris pada file lain.
M enurut Fathansyah (1999, p5), pemanfaatan basis data dapat
dilakukan untuk memenuhi sejumlah tujuan seperti:
•
Kecepatan dan kemudahan (speed)
•
Efisiensi ruang penyimpanan (space)
•
Keakuratan (accurancy)
11
•
Ketersediaan (availability)
•
Kelengkapan (completeness)
•
Keamanan (security)
•
Kebersamaan pemakai (sharability)
Intinya, basis data merupakan lemari berkas kabinet elektronik
yang dapat menyediakan inti dari informasi umum dalam sebuah
program.
2.1.2.
Pengertian Sistem Manajemen Basis Data
M enurut Connolly (2005, p16), sistem manajemen basis data
adalah sistem software yang memungkinkan pemakai (user) untuk
mendefinisikan, membuat, memelihara, dan mengendalikan akses ke
basis data. Sedangkan menurut Ramakrishnan (2003, p4), sistem
manajemen basis data adalah software yang dirancang untuk mendukung
dalam pemeliharaan dan pemanfaatan koleksi data dalam jumlah besar.
Pakar lain, Silberschatz (2002, p1), mengatakan bahwa sistem
manajemen basis data adalah kumpulan data yang saling berhubungan
dan kumpulan program untuk mengakses data-data tersebut. Kumpulan
data biasanya merujuk kepada basis data, mengandung informasi yang
relevan dengan perusahaan.
Tujuan utama DBM S adalah untuk menyediakan dan memperoleh
informasi basis data yang nyaman (convenient) dan efisien. Sistem basis
data dirancang untuk mengatur sejumlah besar informasi, manajemen
12
data termasuk menjelaskan struktur untuk penyimpanan informasi dan
menyediakan mekanisme untuk manipulasi informasi.
2.1.3.
Komponen dari Lingkungan DBMS
Gambar 2.1
Komponen Lingkungan DBMS
M enurut Connolly (2005, pp18-21), terdapat lima komponen
utama dalam lingkungan DBM S, yaitu :
1. Perangkat Keras (Hardware), terdiri dari :
•
Penyimpanan secondary (Magnetic Disk), I/O Device (contoh:
Disk Drive), Device Controller, I/O Channels, dan lain-lain
•
Hardware processor dan main memory, digunakan untuk
mendukung saat eksekusi system software database
2. Perangkat Lunak (Software), terdiri dari : DBM S, sistem operasi,
software jaringan dan program aplikasi.
3. Data, digunakan oleh organisasi dan digambarkan dalam bentuk
skema.
4. Prosedur adalah instruksi dan aturan yang harus diterapkan untuk
mengatur perancangan dan penggunaan basis data dan DBM S.
Pengguna sistem tersebut dan karyawan yang mengelola basis data
13
memerlukan dokumentasi prosedur dan bagaimana sistem itu
dijalankan. Prosedur tersebut meliputi :
•
M asuk ke dalam DBM S
•
M enggunakan fasilitas DBM S atau aplikasi program
•
M emulai dan menghentikan DBM S
•
M embuat backup dan recovery basis data
•
M enangani kesalahan perangkat keras dan perangkat lunak
5. Orang adalah komponen yang terkait dengan sistem. Orang dibagi
menjadi 4, yaitu:
•
Data and Database Administrator
Data
manajemen
perencanaan
Administrator
dari
sumber
(planning),
bertanggung
data
(data
pengembangan
jawab
terhadap
resource)
termasuk
(development)
dan
pemeliharaan (maintenance) basis data dari standard, kebijakan
(policy), prosedur (procedure) dan perancangan basis data
konseptual dan logikal.
Database
Administrator
bertanggung
jawab
untuk
merealisasikan basis data secara fisik, termasuk perancangan basis
data fisikal dan implementasi (implementation), security dan
integrity control, memelihara sistem operasional (operational
system) dan memastikan satisfactory performance dari aplikasi
yang dibuat untuk user.
•
Database Designer
14
Pada proyek perancangan basis data, Database Designer
dapat dibedakan menjadi 2, yaitu Logical Database Designer
yang bertanggung jawab untuk mengenali data (yaitu: entity dan
atribut), hubungan (relationship) antar data dan constraint pada
data yang akan disimpan di dalam basis data. Dan Physical
Database Designer yang bertanggung jawab untuk menentukan
bagaimana perancangan basis data logikal dapat diwujudkan
secara fisik.
•
Application Developers
Bertanggung jawab untuk mengimplementasikan program
aplikasi yang dapat menyediakan fungsionalitas yang dibutuhkan
oleh End-Users.
•
End-Users
End-Users adalah ‘klien’ dari basis data yang dirancang,
diimplementasi dan dipelihara untuk memenuhi kebutuhan
informasi dari End-Users. End-Users sendiri dapat dibedakan
menjadi 2, yaitu : Naïve User dan Sophisticated User.
2.1.4.
Keuntungan dan Kerugian DBMS
M enurut Connolly (2005, pp26-30), sistem manajemen basis data
memiliki keuntungan sekaligus kerugian.
Keuntungan DBM S :
1. Kontrol terhadap redudansi data (Control of data redundancy)
15
Pendekatan basis data mencoba menghapus redudansi dengan
menggabungkan file-file sehingga salinan data yang sama tidak
disimpan.
2. Konsisten (Data consistency)
Basis data membantu menghilangkan atau mengatur redudansi. Hal
ini akan mengurangi terjadinya data yang tidak konsisten antar tabel
yang satu dengan yang lain ataupun antar basis data..
3. Informasi lebih dari jumlah data yang sama (More information from
the same amount of data)
Dengan integrasi data operasional, hal ini akan memungkinkan
perusahaan untuk mendapatkan tambahan informasi dari data yang
sama.
4. Pembagian data (Data sharing)
Basis data dimiliki oleh seluruh organisasi dan dapat dibagi oleh
semua user yang memiliki hak akses. Dengan demikian, banyak user
akan dapat membagi banyak data.
5. Perbaikan integritas data (Improved data integrity)
Database integrity menunjuk pada keabsahan dan konsistensi dari
data yang disimpan.
6. Perbaikan keamanan (Improved security)
Database security adalah pelindung basis data dari user yang tidak
memiliki hak akses. Tanpa keamanan yang tepat, integrasi hanya akan
membuat data menjadi lebih mudah diserang.
16
7. Enforcement of standards
Integrasi
membolehkan
DBA
untuk
menentukan
dan
menyelenggarakan standard yang diperlukan.
8. Skala ekonomi (Economy of Scale)
Dengan menggabungkan data operasional suatu perusahaan ke dalam
satu basis data, dan membuat sebuah kumpulan aplikasi yang berkerja
pada satu sumber data, akan dapat menghemat pengeluaran suatu
perusahaan.
9. Penyeimbangan terhadap conflicting
requirement (Balance of
conflicting requirements)
Setiap user atau departemen memiliki kebutuhan yang berbeda akan
data. Karena basis data berada di bawah control DBSA, maka DBA
dapat membuat keputusan tentang perancangan dan operasional dari
suatu basis data.
10. Perbaikan akses data dan responsibilitas (Improved data accessibility
and responsiveness)
Sebagai hasil dari integrasi, data yang melewati batas departemen
dapat diakses oleh end-user. Hal ini akan menghasilkan sebuah sistem
dengan fungsionalitas yang tinggi.
11. Peningkatan produktivitas (Increase productivity)
DBM S menyediakan banyak fungsi standar yang dapat memudahkan
programmer. DBM S juga menyediakan sebuah lingkungan fourthgeneration yang memudahkan programmer dalam mengembangkan
17
aplikasi
basis
data.
Fungsi-fungsi
ini
akan
meningkatkan
produktivitas programmer dan mengurangi waktu yang digunakan
untuk pengembangan.
12. Perbaikan maintenance melalui data independence (Improved
maintenance through data independence)
DBM S memisahkan deskripsi mengenai data dengan aplikasi. Hal ini
akan membuat aplikasi bebas untuk berubah dalam data description.
Hal inilah yang disebut dengan data independence.
13. Peningkatan concurrency (Increase concurrency)
DBM S akan mengatur akses basis data secara bersamaan dan
memastikan agar tidak terjadi kehilangan informasi atau integritas.
14. Perbaikan pelayanan backup dan recovery (Improves backup and
recovery services)
DBM S menyediakan fasilitas yang dapat mengurangi proses yang
akan mengalami kegagalan.
Kerugian DBM S :
1. Kompleksitas (Complexity)
Ketentuan-ketentuan dari fungsionalitas yang kita harapkan dari
sebuah DBM S yang baik membuat DBM S menjadi sebuah bagian
dari software yang sangat rumit.
2. Ukuran (Size)
Kompleksitas dan luasnya fungsionalitas yang dimiliki DBM S
membuat DBM S menjadi sebuah bagian software yang besar, yang
18
menempati banyak megabyte dari disk space dan membutuhkan
ukuran memori yang besar untuk dapat berjalan dengan efisien.
3. Biaya DBM S (Cost of DBMSs)
Biaya DBM S berubah-ubah secara signifikan, tergantung pada
lingkungan dan fungsionalitas yang disediakan.
4. Biaya perangkat keras tambahan (Additional hardware costs)
Kebutuhan akan tempat penyimpanan untuk DBM S dan basis data
mengharuskan untuk membeli tempat penyimpanan tambahan.
Selanjutnya untuk mencapai kinerja yang dibutuhkan, diperlukan
untuk membeli alat yang lebih besar, bahkan sebuah alat khusus yang
ditujukan untuk menjalankan DBM S.
5. Biaya konversi (Cost of conversion)
Dalam beberapa situasi, biaya DBM S dan hardware tambahan tidak
bisa dibandingkan dengan biaya konversi aplikasi yang sudah ada
untuk dijalankan pada DBM S dan hardware yang baru. Biaya ini
termasuk biaya pelatihan staff untuk dapat menggunakan sistem yang
baru, dan biaya memperkerjakan specialist staff untuk membantu
dalam
konversi dan
menjalankan
sistem.
Hal
inilah
yang
menyebabkan mengapa beberapa organisasi merasa terikat dengan
sistem yang sudah ada dan tidak ingin pindah ke teknologi basis data
yang lebih modern.
6. Kinerja (Performance)
19
Pada umumnya, sebuah sistem berbasis file hanya ‘ditulis’ untuk
aplikasi tertentu, seperti invoicing. Sebagai hasilnya, sistem tersebut
memiliki performance yang baik. Sedangkan DBM S ‘ditulis’ untuk
memenuhi banyak aplikasi. Hal ini mengakibatkan beberapa aplikasi
tidak dapat berjalan secepat biasanya.
7. Dampak dari kegagalan lebih besar (Higher impact of failure)
Sumber yang terpusat meningkatkan kemungkinan sistem untuk
mudah terkena serangan. Karena semua user dan aplikasi bergantung
pada ketersediaan DBM S, Kegagalan beberapa komponen dapat
menghentikan operasi.
2.1.5.
Database Languages
M enurut Connolly (2005, pp39-42), sebuah data sublanguage
terdiri dari dua bagian, yaitu :
1. Data Definition Language (DDL)
Sebuah bahasa (language) yang membolehkan DBA atau user
untuk menggambarkan dan memberi nama entity, atribut, dan
hubungan (relationship) yang dibutuhkan aplikasi, bersama dengan
associated integrity dan security constraints.
Hasil kumpulan dari statement DDL adalah satu kumpulan
tabel yang menyimpan file khusus secara bersama dinamakan sistem
katalog. Sistem katalog yang mengintegrasikan meta data.
20
M eta data adalah data yang menggambarkan objek dalam
basis data dan membuatnya lebih mudah untuk diakses dan
dimanipulasi. M eta data berisi definisi dari record, data item, objek
lain yang menjadi minat ke para pemakai atau diperlukan oleh
DBM S. DBM S secara normal berkonsultasi kepada sistem katalog
sebelum data yang aktual diakses dalam basis data.
2. Data Manipulation Language (DML)
Sebuah bahasa (language) yang menyediakan satu set operasi
yang digunakan untuk mendukung operasi manipulasi pada data yang
disimpan di dalam basis data.
Operasi manipulasi pada data meliputi :
•
M enambahkan data baru ke dalam basis data
•
M emodifikasi data yang tersimpan dalam basis data
•
M emperoleh kembali data yang terdapat dalam basis data
•
M enghapus data dari basis data
DM L dibedakan oleh perolehan bentuk dasar pencarian
mereka, kita dapat membedakan dalam 2 jenis DML yaitu :
•
Procedural DML
Suatu bahasa yang memungkinkan pengguna untuk memberi
instruksi ke sistem mengenai data yang dibutuhkan dan cara
pemanggilannya. Artinya, pengguna harus menjelaskan operasi
pengaksesan data yang akan digunakan dengan menggunakan
21
prosedur
yang ada
untuk
mendapatkan
informasi
yang
dibutuhkan.
•
Non-procedural DML
Suatu bahasa yang memungkinkan pengguna untuk menentukan
data yang dibutuhkan dengan menyebutkan spesifikasinya tanpa
men-spesifikasikan bagaimana cara mendapatkannya.
2.1.6.
Fungsi DBMS
M enurut Codd (1982), terdapat 8 fungsi yang seharusnya
disediakan oleh DBM S. Dan Connolly (2005, pp48-52) menambahkan 2
fungsi yang diharapkan ada. Fungsi-fungsi tersebut adalah
1. Tempat penyimpanan, penerimaan, dan pembaharuan data
Sebuah DBM S harus melengkapi user dengan kemampuan untuk
menyimpan, mendapatkan kembali, dan memperbaharui data di dalam
database.
2. Sebuah katalog yang user-accessible
Sebuah DBM S harus dilengkapi dengan sebuah catalog yang di
dalamnya berisi deskripsi dari item data yang disimpan dan dapat
diakses oleh user.
3. M endukung transaksi
Sebuah DBM S harus dilengkapi dengan sebuah mekanisme yang
akan menjamin bahwa semua update yang cocok dengan transaksi
yang diberikan dibuat atau tidak dibuat sama sekali.
22
4. M endukung kendali concurrency
Sebuah DBM S harus dilengkapi dengan sebuah mekanisme untuk
memastikan bahwa basis data diperbaharui secara benar pada saat
banyak pemakai melakukan proses update secara bersamaan.
5. Recovery service
Sebuah DBM S harus dilengkapi dengan sebuah mekanisme untuk
mengembalikan (recovering) basis data pada saat basis data
mengalami kerusakan.
6. Authorization service
Sebuah DBM S harus dilengkapi dengan sebuah mekanisme yang
menjamin bahwa hanya user yang memiliki hak akses yang dapat
mengakses basis data.
7. M endukung komunikasi antar data
Sebuah DBM S harus dapat terintegrasi dengan software komunikasi.
8. Integrity service
Sebuah DBM S harus dilengkapi dengan arti (means) untuk
memastikan data di dalam basis data dan perubahan pada data
mengikuti aturan tertentu.
9. Data independent service
Sebuah DBM S harus termasuk fasilitas untuk mendukung program
yang independen dari struktur sebenarnya dari basis data.
10. Utility services
Sebuah DBM S harus menyediakan sebuah set utility service.
23
2.1.7.
Relational Model
Relational model dibuat berdasarkan konsep matematika dari
sebuah relasi, yang secara fisik ditampilkan sebagai tabel.
2.1.7.1.
Relational Data Structure
M enurut Connolly (2005, pp72-74), terdapat beberapa
istilah, yaitu :
•
Relasi (Relation) adalah tabel dengan kolom dan baris
•
Atribut (Attribute) adalah nama kolom dari sebuah relasi
•
Domain adalah kumpulan nilai yang diperbolehkan untuk
satu atau lebih atribut
•
Tuple adalah baris dari sebuah relasi
•
Derajat (Degree) sebuah relasi adalah banyaknya atribut
yang terkandung di dalam sebuah relasi
•
Cardinality sebuah relasi adalah banyaknya tuple yang
terkandung di dalam sebuah relasi
•
Relational Database sebuah koleksi dari relasi yang
ternomalisasi dengan nama relasi yang berbeda
2.1.7.2.
Database Relations
M enurut Connolly (2005, p76), database relational
dibagi 2:
24
•
Relation Schema
Sebuah relasi bernama yang ditetapkan oleh kumpulan
atribut dan nama domain berpasangan.
•
Relational Database Schema
Kumpulan dari relation schema, setiap relation schema
memiliki nama yang berbeda.
2.1.7.3.
Relational Key
Seperti yang dijelaskan sebelumnya, tidak ada tuple
yang sama dalam sebuah relasi. Sehingga kita perlu untuk
mengenali satu atau lebih atribut (disebut relational key) yang
secara unik mengenali setiap tuple dalam sebuah relasi.
M enurut Connolly (2005, pp78-79), relational key
dibagi menjadi 4 :
1. Superkey
Sebuah atribut atau kumpulan atribut, yang secara unik
menegaskan sebuah tuple dalam sebuah relasi.
2. Candidate Key
Sebuah superkey dimana tidak ada proper subset yang
menjadi superkey di dalam relasi.
3. Primary Key
Candidate key yang dipilih untuk menegaskan secara unik
sebuah tuple dalam sebuah relasi.
25
4. Foreign Key
Sebuah atribut atau kumpulan atribut, dalam sebuah relasi
yang cocok dengan candidate key dari beberapa relasi
(kemungkinan sama).
2.1.7.4.
Integrity Constraints
Sebelum menjelaskan lebih jauh mengenai integrity
constraint, ada baiknya kita mengerti mengenai konsep null.
M enurut Connolly (2005, 81), null menampilkan sebuah nilai
untuk sebuah atribut yang tidak diketahui atau tidak dapat
diterapkan untuk tuple ini.
M enurut Connolly (2005, pp82-83), terdapat 2 aturan
utama dalam relational model, yaitu :
1. Entity Integrity
Dalam relasi dasar, tidak ada atribut dari primary key yang
bernilai null.
2. Referential Integrity
Jika sebuah foreign key ada di dalam sebuah relasi, nilai
foreign key harus sesuai dengan nilai candidate key dari
beberapa tuple di dalam relasi asal atau nilai foreign key
harus bernilai null.
M enurut Connolly (2005, p83), ada 2 tipe integrity
constraint yaitu :
26
1. General Constraints
Aturan tambahan yang ditetapkan oleh user atau DBA dari
sebuah basis data yang menentukan atau memaksa
beberapa aspek dari sebuah perusahaan.
2. Multiplicity
Untuk multiplicity, akan dijelaskan pada bagian 2.1.10.6
2.1.8.
Database System Development Lifecycle
Untuk merancang aplikasi sistem basis data, tahapan-tahapan
terstruktur yang harus diikuti dinamakan dengan Siklus Pengembangan
Sistem Basis Data (Database System Development Lifecycle). Perlu
diingat bahwa tahapan dalam DSDL tidak harus berurutan, namun juga
melibatkan beberapa pengulangan ke tahapan sebelumnya melalui
putaran balik (feedback loops). Tahapan-tahapan tersebut terlihat pada
gambar 2.1 (Connolly, 2005, p284).
27
Gambar 2.2 Database System Development Lifecycle
2.1.8.1.
Perencanaan Basis Data (Database Planning)
Perencanaan
bagaimana
basis
data merupakan
tahapan-tahapan
dalam
perencanaan
lifecycle
dapat
direalisasikan seefektif dan seefisien mungkin. Perencanaan
basis data harus terintegrasi dengan keseluruhan strategi
sistem informasi dari organisasi.
28
Terdapat 3 hal pokok yang berkaitan dengan strategi
sistem informasi, yaitu :
1. Identifikasi rencana dan sasaran (goals) dari enterprise
termasuk mengenai sistem informasi yang dibutuhkan.
2. Evaluasi sistem informasi yang ada untuk menetapkan
kelebihan dan kekurangan yang dimiliki.
3. Penaksiran kesempatan IT yang mungkin memberikan
keuntungan kompetitif.
M etodologi untuk mengatasi hal tersebut diatas yaitu :
•
Database Planning – Mission Statement
Mission statement untuk proyek basis data mendefinisikan
tujuan utama dari aplikasi basis data. Mission statement
membantu menjelaskan kegunaan dari proyek basis data
dan menyediakan alur yang lebih jelas untuk mencapai
efektifitas dan efisiensi penciptaan dari suatu aplikasi basis
data yang diinginkan.
•
Database Planning – Mission Objectives
Ketika mission statement telah didefinisikan, maka
mission objectives didefinisikan. Setiap tujuan (objective)
harus mengidentifikasikan tugas khusus yang harus
didukung oleh basis data. Dapat juga disertai dengan
beberapa informasi tambahan yang menspesifikasikan
29
pekerjaan yang harus diselesaikan, sumber daya yang
digunakan dan biaya untuk membayar kesemuanya itu.
2.1.8.2.
Pendefinisian Sistem (System Definition)
System Definition menjelaskan batasan-batasan dan
cakupan dari aplikasi basis data dan sudut pandang pemakai
yang utama. Sudut pandang pemakai mendefinisikan apa yang
diwajibkan dari suatu aplikasi basis data dari perspektif aturan
kerja khusus atau area aplikasi perusahaan. Sudut pandang
pemakai diperlukan untuk memastikan bahwa tidak ada
pemakai utama dari suatu basis data yang terlupakan ketika
pembuatan aplikasi baru yang dibutuhkan dan membantu
dalam pengembangan aplikasi basis data yang rumit atau
komplek juga memungkinkan permintaan-permintaan dipecah
ke dalam bagian-bagian yang lebih simpel.
2.1.8.3.
Pengumpulan
dan
Analisa Kebutuhan
(Requirement
Collection and Analysis)
Analisis dan pengumpulan kebutuhan merupakan suatu
proses pengumpulan dan analisis informasi mengenai bagian
organisasi yang didukung oleh aplikasi basis data, dan
menggunakan informasi tersebut untuk identifikasi kebutuhan
30
pemakai akan sistem yang baru. Informasi yang dikumpulkan
untuk setiap user view utama meliputi :
•
Deskripsi data yang digunakan atau dihasilkan.
•
Detail
mengenai
bagaimana
data
digunakan
atau
dihasilkan.
•
Beberapa kebutuhan tambahan untuk aplikasi basis data
yang baru.
Informasi dianalisis untuk identifikasi kebutuhan agar
disertakan dalam aplikasi basis data yang baru.
penting lainnya ialah
menentukan
Aktivitas
bagaimana caranya
mengatur aplikasi basis data dengan multiple user view, yaitu :
•
Pendekatan Terpusat (Centralized approach)
Kebutuhan untuk setiap user view digabungkan
menjadi sekumpulan kebutuhan. Sebuah
global data
model dibuat berdasarkan atas penggabungan kebutuhan
(dimana menampilkan seluruh user view).
•
Pendekatan Integrasi View (View integration approach)
Kebutuhan untuk setiap user view digunakan untuk
membangun model data terpisah untuk merepresentasikan
user view tersebut. Hasil dari model data tersebut nantinya
digabungkan dalam tahapan desain basis data.
M odel-model yang menampilkan user view tunggal
disebut local data model, dan tersusun atas diagram-
31
diagram
dan
dokumentasi
yang
menggambarkan
kebutuhan
dari user
terhadap
data. Kemudian local data
basis
secara
formal
view khusus
model
digabungkan untuk menghasilkan global data model, yang
menampilkan seluruh user view untuk basis data.
•
2.1.8.4.
Kombinasi keduanya (Combination of both approaches)
Perancangan Basis Data (Database Design)
Perancangan basis data merupakan suatu proses
pembuatan
sebuah
rancangan
basis
data
yang
mendukung tujuan dan operasi suatu perusahaan.
akan
Tujuan
utamanya adalah :
•
M enampilkan data dan relationship antar data yang
dibutuhkan oleh seluruh area aplikasi utama dan user
group.
•
M enyediakan
model data yang mendukung segala
transaksi yang diperlukan pada data.
•
M enspesifikasikan rancangan minimal yang yang secara
tepat disusun untuk memenuhi kebutuhan performa yang
ditetapkan pada sistem (misal : waktu respon).
Pendekatan dalam desain basis data :
•
Top-down
32
Diawali dengan pembentukan model data yang
berisi beberapa entitas high-level dan relationship, yang
kemudian menggunakan pendekatan top-down secara
berturut-turut untuk mengindentifikasikan entitas lower
level, relationship dan atribut lainnya.
•
Bottom-up
Dimulai dari atribut dasar (yaitu, sifat-sifat entitas dan
relationship), dengan analisis dari penggabungan antar
atribut, yang dikelompokan kedalam suatu relasi yang
menampilkan tipe dari entitas dan relationship antar
entitas.
•
Inside-out
Berhubungan dengan pendekatan bottom-up tetapi sedikit
berbeda dengan identifikasi awal entitas utama dan
kemudian menyebar ke entitas, relationship, dan atribut
terkait lainnya yang lebih dulu diidentifikasi.
•
Mixed
M enggunakan pendekatan bottom-up dan top-down untuk
bagian yang berbeda sebelum pada akhirnya digabungkan.
M enurut Connolly (2005, pp293-295), terdapat 3 fase
dalam perancangan basis data, yaitu :
•
Perancangan
Basis
Database Design)
Data
Konseptual
(Conceptual
33
Suatu proses pembentukan model dari informasi yang
digunakan dalam perusahaan, independen dari keseluruhan
aspek fisik. M odel data dibangun dengan menggunakan
informasi dalam spesifikasi kebutuhan pemakai. M odel
data konseptual merupakan sumber informasi untuk tahap
perancangan logikal.
•
Perancangan Basis Data Logikal (Logical Database
Design)
Suatu proses pembentukan model dari informasi yang
digunakan dalam perusahaan berdasarkan model data
tertentu (misal : relasional), tetapi independen terhadap
DBM S tertentu dan aspek fisik lainnya. M odel data
konseptual yang telah dibuat sebelumnya, diperbaiki dan
dipetakan kedalam model data logikal.
•
Perancangan Basis Data Fisikal (Physical Database
Design)
Suatu proses yang menghasilkan deskripsi implementasi
basis data pada penyimpanan sekunder. Perancanga ini
menggambarkan struktur penyimpanan dan metode akses
yang digunakan untuk mencapai akses yang efisien
terhadap data. Dapat dikatakan juga, desain fisikal
merupakan tahap perancangan terakhir menuju sistem
DBM S tertentu.
34
2.1.8.5.
Pemilihan DBMS (DBMS Selection)
Pemilihan DBM S yang tepat untuk mendukung
aplikasi basis data. Dapat dilakukan kapanpun sebelum
menuju perancangan logikal asalkan terdapat cukup informasi
mengenai kebutuhan sistem. Tahap-tahap
utama untuk
memilih DBM S :
2.1.8.6.
•
M endefinisikan terminologi studi referensi.
•
M endaftarkan dua atau tiga produk.
•
Evaluasi produk.
•
Rekomendasi pilihan dan laporan produk.
Perancangan Aplikasi (Application Design)
Perancangan
aplikasi
adalah
perancangan
user
interface dan program aplikasi yang menggunakan dan
memproses basis data. Perancangan basis data dan aplikasi
merupakan aktivitas paralel yang meliputi dua aktivitas
penting, yaitu :
1. Perancangan Transaksi (Transaction Design)
Transaksi adalah satu aksi atau serangkaian aksi yang
dilakukan oleh user tunggal atau program aplikasi, yang
mengakses atau mengubah isi dari basis data. Kegunaan
dari desain transaksi adalah untuk menetapkan dan
menerangkan karakteristik high-level dari suatu transaksi
35
yang dibutuhkan pada basis data. Terdapat tiga tipe
transaksi, yaitu :
•
Retrieval Transaction, digunakan untuk pemanggilan
(retrieve) data untuk ditampilkan di layar atau
menghasilkan suatu laporan.
•
Update Transaction, digunakan untuk menambahkan
record
baru,
menghapus
record
lama,
atau
memodifikasi record yang sudah ada didalam basis
data.
•
Mixed
Transaction,
meliputi
pemanggilan
dan
perubahan data.
2. Perancangan Tampilan Pemakai (User Interface Design)
Beberapa aturan pokok dalam perancangan user interface :
•
Meaningful title, diusahakan pemberian nama suatu
form cukup jelas menerangkan kegunaan dari suatu
form/report.
•
Comprehensible instructions, penggunaan terminologi
yang familiar untuk menyampaikan instruksi ke user
dan jika informasi tambahan dibutuhkan, maka harus
disediakan helpscreen.
•
Logical grouping and sequencing of fields, field yang
saling berhubungan ditempatkan pada form/report
yang sama. Urutan field harus logis dan konsisten.
36
•
Visually appealing layout of the form/report, tampilan
form/report harus
menarik,
dan
sesuai dengan
hardcopy agar konsisten.
•
Familiar field labels, penggunaan label yang familiar.
•
Consistent terminology and abbreviation, terminologi
dan singkatan yang digunakan harus konsisten.
•
Consistent use of color
•
Visible space and boundaries for data-entry fields,
jumlah tempat yang disediakan untuk data entry harus
diketahui oleh user.
•
Convinient cursor movement, user dapat dengan
mudah menjalankan operasi yang diinginkan dengan
menggerakkan kursor pada form/report.
•
Error correction for individual characters and entire
fields, user dapat dengan mudah menjalankan operasi
yang diinginkan dan melakukan perubahan terhadap
nilai field.
•
Error messages for unacceptable values.
•
Optional fields marked clearly.
•
Explanatory
messages
for
fields,
ketika
user
meletakkan kursor pada suatu field, maka keterangan
mengenai field tersebut harus dapat dilihat.
37
2.1.8.7.
Protoyping
Prototyping adalah pembuatan model kerja suatu
aplikasi basis data. Tujuan utama dari pembuatan prototyping:
•
Untuk mengidentifikasi feature dari sistem apakah
berjalan dengan baik atau tidak.
•
Untuk memberikan perbaikan-perbaikan atau penambahan
feature baru.
•
Untuk klarifikasi kebutuhan customer.
•
Untuk evaluasi feasibilitas (kemungkinan yang akan
terjadi) dari desain sistem khusus.
Terdapat dua macam strategi prototyping yang
digunakan saat ini, yaitu:
•
Requirements prototyping, menggunakan prototype untuk
menentukan kebutuhan dari aplikasi basis data yang
diinginkan dan ketika kebutuhan itu terpenuhi maka
prototype akan dibuang.
•
Evolutionary prototyping, digunakan untuk tujuan yang
sama. Perbedaannya, prototype tidak dibuang tetapi
dengan pengembangan lanjutan menjadi aplikasi basis
data yang digunakan.
38
2.1.8.8.
Implementasi (Implementation)
Implementasi merupakan realisasi fisik dari basis data
dan perancangan aplikasi. Implementasi basis data dicapai
dengan menggunakan :
•
DDL untuk membuat skema basis data dan file basis data
kosong.
•
DDL untuk membuat user view yang diinginkan.
M enggunakan 3GL dan 4GL untuk membuat program
aplikasi. Transaksi basis data juga turut disertakan dengan
menggunakan
DM L,
atau
ditambahkan
pada
bahasa
pemrograman.
2.1.8.9.
Konversi Data dan Pemuatan (Data Conversion and
Loading)
Pemindahan data yang ada ke dalam basis data baru
dan merubah (conversion) aplikasi yang ada agar dapat
digunakan pada basis data yang baru. Tahapan ini dibutuhkan
ketika sistem basis data baru menggantikan sistem yang lama.
DBM S biasanya memiliki utilitas yang memanggil ulang file
yang sudah ada ke dalam basis data baru. Dapat juga merubah
(conversion) dan menggunakan program aplikasi dari sistem
yang lama untuk digunakan oleh sistem yang baru.
39
2.1.8.10.
Pengujian (Testing)
Testing adalah suatu proses eksekusi program aplikasi
dengan
tujuan
untuk
menemukan
kesalahan
dengan
menggunakan strategi tes yang direncanakan dan data yang
sesungguhnya. Pengujian hanya akan terlihat jika terjadi
kesalahan
software.
Dengan
adanya pengujian,
maka
kesalahan yang terjadi dapat segera diketahui dan diperbaiki
sebelum diimplementasikan secara sempurna.
2.1.8.11.
Pemeliharaan Operasional (Operational Maintenance)
Suatu proses pengawasan dan pemeliharaan sistem
setelah instalasi, meliputi :
•
Pengawasan performa sistem, jika performa menurun,
sehingga memerlukan perbaikan atau pengaturan ulang
basis data.
•
Pemeliharaan dan pembaharuan aplikasi basis data (jika
dibutuhkan).
•
Penggabungan kebutuhan baru ke dalam aplikasi basis
data.
2.1.9.
Data Administration and Database Administration
M enurut Connolly (2005, p309), terdapat data administration dan
database administration yang bertanggung jawab untuk mengatur dan
40
mengawasi aktivitas yang berhubungan dengan data dan basis data
perusahaan.
Data administration adalah pengaturan sumber data, dimana
termasuk database planning, pengembangan dan pemeliharaan standard,
policy dan prosedur serta perancangan basis data konseptual dan logikal.
Database administration adalah pengaturan dari realisasi fisik
suatu sistem basis data, dimana termasuk perancangan basis data fisikal,
implementation, pengaturan keamanan dan integrity control, mengawasi
performa sistem, dan mengatur kembali basis data.
2.1.10.
Entity-Relationship Modeling
ER (Entity Relationship) data model didasarkan pada persepsi
dunia nyata yang terdiri dari kumpulan objek dasar, yang disebut entiti
dan hubungan antara objek-objek ini.
2.1.10.1.
Jenis Entiti (Entity Type)
Tipe entity merupakan konsep dasar dari suatu model
ER. M enurut Connolly (2005, p343), Entity type adalah
kumpulan dari objek dengan properti yang sama, yang
dikenali oleh perusahaan dan mempunyai keberadaan yang
independen. Keberadaan entity type dapat berupa fisik atau
‘nyata’ dan konseptual atau abstrak. Sedangkan Entity
41
occurrence adalah pengenalan objek yang unik dari sebuah
entity type.
Gambar 2.3
2.1.10.2.
Jenis Entiti
Jenis Relasi (Relationship Types)
M enurut Connolly (2005, p347), Relationship type
adalah kumpulan hubungan yang mempunyai arti antara entity
Sementara Relationship
type.
hubungan
yang
dikenali
occurrence
secara unik,
merupakan
yang
meliputi
keberadaan dari setiap entity type yang berpartisipasi.
M enurut Connolly (2005, pp347-348), Degree of
Relationship
berpartisipasi
Type
dalam
adalah
sebuah
jumlah
entity
relationship.
type
yang
Degree
Relationship Type terdiri dari :
•
Binary Relationship : Hubungan antara dua entity type.
of
42
Gambar 2.4 Binary Relationship
•
Ternary Relationship : Hubungan antara tiga entity type.
Gambar 2.5
•
Ternary Relationship
Quaternary Relationship : Hubungan antara empat entity
type.
Gambar 2.6 Quaternary Relationship
43
M enurut
Connolly
(2005,
pp349),
recursive
relationship adalah hubungan antara satu entity type dimana
entity type tersebut berpartisipasi lebih dari satu kali dengan
peran yang berbeda. Disebut juga Unary Relationship.
Gambar 2.7 Recursive Relationship
2.1.10.3.
Atribut (Attribute)
M enurut Connolly (2005, pp350-354), Atribut adalah
properti dari sebuah entity atau relationship type. Contohnya :
sebuah entity karyawan digambarkan oleh kdKary, nmKary,
almtKary dan jabatan.
M acam-macam Atribut :
•
Attribute Domain
himpunan nilai yang diperbolehkan untuk satu atau lebih
atribut.
•
Simple Attribute atau Atomic Attribute
44
Atribut yang terdiri dari satu komponen tunggal dengan
keberadaan yang independen dan tidak dapat dibagi
menjadi bagian yang lebih kecil lagi.
•
Composite Attribute
Atribut yang terdiri dari beberapa komponen dimana
masing-masing komponen memiliki keberadaan yang
independen. M isalkan atribut alamat dapat terdiri dari
jalan, kota dan kode pos.
•
Single-value Attribute
Atribut yang mempunyai nilai tunggal untuk setiap
kejadian. M isalnya entity pemesanan memiliki satu nilai
untuk attribut noPesan pada setiap kejadian.
•
Multi-value Attribute
Atribut yang mempunyai beberapa nilai untuk setiap
kejadian. M isalnya entity Karyawan memiliki beberapa
nilai untuk attribut noTelp pada setiap kejadian.
•
Derived Attribute
Atribut yang menampilkan nilai yang dihasilkan dari satu
atau beberapa atribut lainnya, dan tidak harus berasal dari
satu entity type yang sama.
45
2.1.10.4.
Key
Kita harus memiliki cara untuk menspesifikasikan
bagaimana entity di dalam kumpulan entity dapat dibedakan.
M aka, nilai dari atribut sebuah entity harus sedemikian rupa
agar dapat mengidentifikasi entity secara unik. Sebuah key
memberikan kemudahan untuk mengidentifikasi kumpulan
atribut yang mencukupi untuk dapat membedakan entity yang
satu dengan yang lain. Key juga membantu mengenali
relationship secara unik serta membedakan relationship antara
yang satu dengan yang lainnya.
M enurut Connolly (2005, pp352-353),Key terbagi atas:
•
Candidate Key
Candidate Key didefinisikan sebagai jumlah minimal dari
atribut-atribut yang secara unik mengenali setiap kejadian
dari sebuah entity type.
•
Primary Key
Primary Key didefinisikan sebagai candidate key yang
dipilih secara unik untuk mengenali setiap kejadian dari
sebuah entity type.
•
Composite Key
Composite Key didefinisikan sebagai candidate key yang
terdiri atas dua atau lebih atribut.
46
2.1.10.5.
Strong and Weak Entity
M enurut Connolly (2005, pp354-355), Strong entity
type adalah entity type yang keberadaannya tidak tergantung
pada jenis entity lainnya. Sedangkan weak entity type adalah
jenis entity yang keberadaannya tergantung pada jenis entity
lainnya. Strong entity type disebut juga parent, owner atau
dominant entity sedangkan weak entity type disebut child,
dependent atau subordinate entity.
2.1.10.6.
Structural Constraints
M enurut Connolly (2005, p356), multiplicity adalah
jumlah (atau jarak) kejadian yang mungkin terjadi dari sebuah
entity type yang terhubung dengan entity type yang lain
melalui sebuah relationship tertentu. Seperti yang dijelaskan
sebelumnya, derajat (degree) yang sering digunakan untuk
sebuah relationship adalah binary. Dan menurut Connolly
(2005, pp357-362), binary dibagi menjadi 3 :
•
One-to-One (1:1) Relationships
Gambar 2.8 One-to-One (1:1) Relationships
•
One-to-Many (1:*) Relationships
47
Gambar 2.9 One-to-Many (1:*) Relationships
•
Many-to-Many (*:*) Relationships
Gambar 2.10 Many-to-Many (*:*) Relationships
2.1.10.7.
Cardinality and Participation Constraints
M enurut Connolly (2005, pp362-363), multiplicity
sebenarnya terdiri dari 2 constraint yang berbeda, yaitu :
Cardinality
dan
Participation
Constraint.
Cardinality
menggambarkan jumlah maksimal dari hubungan yang
mungkin terjadi untuk setiap entiti yang berpartisipasi.
Sedangkan participation menentukan apakah semua atau
hanya beberapa entiti yang berpartisipasi dalam sebuah relasi.
48
2.1.11. Normalisasi (Normalization)
Gambar 2.11 Normalisasi
2.1.11.1.
Pengertian Normalisasi
M enurut Connolly (2005, p388), Normalisasi adalah
sebuah teknik untuk menghasilkan sebuah kumpulan relasi
dengan property yang diinginkan, memberikan kebutuhan data
dari sebuah perusahaan.
2.1.11.2.
Functional Dependencies
Sebuah konsep penting yang berhubungan dengan
normalisasi adalah functional dependency yang menjelaskan
hubungan antar atribut-atribut (M aier, 1983).
M enurut Connolly (2005, pp393-399), karakteristik
dari sebuah functional dependency dibagi 3 :
1. Functional Dependency
49
M enjelaskan relationship antara atribut-atribut dalam
sebuah relasi. Sebagai contoh, jika A dan B adalah atribut
dari relasi R, maka B secara fungsional tergantung pada A
(digambarkan A→ B), jika setiap nilai dari A terhubung
secara tepat dengan satu nilai dari B (A dan B dapat terdiri
dari satu atau lebih atribut).
2. Full Functional Dependency
M enunjukkan bahwa jika A dan B adalah atribut dari
sebuah relasi, maka B bergantung secara fungsional
dengan A jika B bergantung pada A namun bukan pada
proper subset dari A.
3. Transitive Dependency
Suatu kondisi dimana A, B dan C adalah atribut dari suatu
relasi sehingga jika A→B dan B→C, maka C bergantung
secara transitif pada A melalui B.
2.1.11.3.
Proses Normalisasi
1. Unnormalized Form (UNF)
M enurut Connolly (2005, p403), UNF adalah sebuah tabel
yang terdiri dari satu atau lebih repeating group.
2. First Normal Form (1NF)
50
M enurut Connolly (2005, p403), 1NF adalah sebuah relasi
dimana titik potong dari setiap baris dan kolom terdiri dari
satu dan hanya satu nilai.
3. Second Normal Form (2NF)
M enurut Connolly (2005, p407), 2NF adalah sebuah relasi
yang terdapat dalam 1NF dan setiap atribut non-primary
key tergantung secara fungsional pada primary key.
4. Third Normal Form (3NF)
M enurut Connolly (2005, pp408-409), 3NF adalah sebuah
relasi yang terdapat dalam 1NF dan 2NF dimana atribut
non-primary key tergantung secara transitif pada primary
key.
2.1.12.
Advanced Normalization
1. Boyce-Codd Normal Form (BCNF)
M enurut Connolly (2005, 419), BCNF adalah sebuah relasi di dalam
BCNF, jika dan hanya jika setiap determinant adalah candidate key.
2. Fourth Normal Form (4NF)
M enurut Connolly (2005, p430), 4NF adalah sebuah relasi di dalam
Boyce-Codd normal form dan tidak terdapat ketergantungan
nontrivial yang multi-valued.
3. Fifth Normal Form (5NF)
51
M enurut Connolly (2005, p431), 5NF adalah Sebuah relasi yang tidak
memiliki join dependency.
2.1.13. Perancangan Basis Data Konseptual (Conceptual Database Design)
Suatu proses pembentukan model dari informasi yang digunakan
dalam perusahaan, independen dari keseluruhan aspek fisik. M odel data
dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan
pemakai. M odel data konseptual merupakan sumber informasi untuk
tahap perancangan logikal.
Langkah-langkah untuk perancangan basis data konseptual :
1. M embangun model data konseptual
Bertujuan untuk membangun model data konseptual dari kebutuhan
data suatu perusahaan.
a. M engenali tipe entity
Bertujuan untuk mengenali tipe entity yang dibutuhkan.
b. M engenali tipe relationship
Bertujuan untuk mengenali relationship penting yang ada di
antara tipe entity
c. M engenali dan menghubungkan atribut dengan entity atau tipe
relationship
Bertujuan untuk menggabungkan atribut-atribut dengan entity
atau tipe relationship yang sesuai.
d. M enentukan attribute domain
52
Bertujuan untuk menentukan domain untuk atribut di dalam
model data konseptual lokal.
e. M enentukan atribut candidate, primary, dan alternate key
Bertujuan untuk mengenali candidate key untuk setiap tipe entity
dan, jika ada lebih dari satu candidate key, maka harus memilih
salah satu sebagai primary key dan yang lainnya sebagai alternate
key.
f. M empertimbangkan penggunaan enhanced modeling concept
(optional)
Bertujuan untuk mempertimbangkan penggunaan enhanced
modeling
concept,
seperti
specialization/generalization,
aggregation dan composition.
g. M emeriksa model untuk redudansi
Bertujuan untuk memeriksa kehadiran dari redundancy di dalam
model.
h. M emvalidasi model konseptual terhadap transaksi user
Bertujuan
untuk
memastikan
bahwa
model
konseptual
mendukung transaksi yang dibutuhkan.
i. M elihat kembali model data konseptual dengan user
Bertujuan untuk melihat kembali model data konseptual dengan
user untuk memastikan bahwa mereka mempertimbangkan model
untuk menjadi tampilan sesungguhnya dari kebutuhan data sebuah
perusahaan.
53
2.1.14.
Perancangan Basis Data Logikal (Logical Database Design)
Suatu proses pembentukan model dari informasi yang digunakan
dalam perusahaan berdasarkan model data tertentu (misal : relasional),
tetapi independen terhadap DBM S tertentu dan aspek fisik lainnya.
M odel data konseptual yang telah dibuat sebelumnya, diperbaiki dan
dipetakan kedalam model data logikal.
Langkah-langkah untuk perancangan basis data logikal :
a
M embangun dan memvalidasi model data logikal
Bertujuan untuk mewujudkan model data konseptual ke dalam
model data logikal dan memvalidasi model untuk memeriksa
apakah sudah benar secara struktur dan mendukung transaksi
yang dibutuhkan.
b. M endapatkan relasi untuk data model logikal
Bertujuan untuk membuat relasi untuk model data logikal yang
menampilkan entity, relationship, dan atribut yang sudah
dikenali.
c. M emvalidasi relasi menggunakan normalisasi
Bertujuan untuk memvalidasi relasi pada model data logikal
menggunakan normalisasi.
d. M emvalidasi relasi terhadap transaksi user
Bertujuan untuk memastikan relasi pada model data logikal
mendukung transaksi yang dibutuhkan.
e. M emeriksa integrity constraint
54
Bertujuan untuk memeriksa integrity constraint yang ditampilkan
pada model data logikal.
f. M elihat kembali model data logika dengan user
Bertujuan untuk melihat kembali model data logikal dengan user
untuk memastikan bahwa mereka menyadari model yang menjadi
representasi yang sebenarnya dari kebutuhan data sebuah
perusahaan.
g. M enggabungkan model data logikal ke dalam model global
(optional)
Bertujuan untuk menggabungkan model data logikal ke dalam
sebuah model data logikal global yang menampilkan semua user
view dari sebuah basis data.
h. M emeriksa untuk pertumbuhan di masa depan
Bertujuan untuk menentukan apakah ada perubahan yang terjadi
secara signifikan dan untuk menilai apakah model data logikal
dapat menampung perubahan tersebut.
2.1.15.
Perancangan Basis Data Fisikal (Physical Database Design)
Perancangan basis data fisikal merupakan suatu proses yang
menghasilkan deskripsi implementasi basis data pada penyimpanan
sekunder serta menggambarkan struktur penyimpanan dan metode akses
yang digunakan untuk mencapai akses yang efisien terhadap data. Dapat
55
dikatakan, desain fisikal juga merupakan cara pembuatan menuju sistem
DBM S tertentu.
Langkah-langkah untuk perancangan basis data fisikal :
a. M ewujudkan model data logical untuk target DBM S
Bertujuan untuk menghasilkan skema relasional basis data dari
model data logikal yang dapat diterapkan pada target DBMS.
b. M erancang relasi dasar
Bertujuan untuk memutuskan bagaimana menampilkan relasi
dasar yang dikenali di model data logikal di dalam target DBMS.
c. M erancang tampilan dari derived data
Bertujuan untuk memutuskan bagaimana menampilkan setiap data
yang didapat di model data logikal di dalam target DBMS.
d. M erancang general constraint
Bertujuan untuk merancang general constraint untuk target
DBMS.
e. M erancang file dan index organisasi
Bertujuan untuk menentukan file organisasi yang optimal untuk
menyimpan relasi dasar dan indeks yang dibutuhkan untuk
mendapatkan kinerja yang dapat diterima. Caranya dengan
menyimpan relasi dan tuple di dalam tempat penyimpanan
secondary.
f.
M enganalisa transaksi
56
Bertujuan untuk memahami fungsionalitas dari transaksi yang
akan dijalankan pada basis data dan untuk menganalisa transaksi
penting.
g. M emilih file organisasi
Bertujuan untuk menentukan file organisasi yang efisien untuk
setiap relasi dasar.
h. M emilih indeks
Bertujuan untuk menentukan apakah dengan menambahkan
indeks akan meningkatkan kinerja dari sistem.
i. M emperkirakan kebutuhan ruang disk
Bertujuan untuk memperkirakan jumlah dari disk yang dibutuhkan
untuk basis data.
j.
M erancang user views
Bertujuan untuk merancang user view yang dikenali selama
requirement collection dan menganalisa database system
development lifecycle.
k. M erancang mekanisme keamanan
Bertujuan untuk merancang mekanisme keamanan untuk basis
data seperti yang ditetapkan user selama requirement dan
collection dari database system development lifecycle.
l.
M empertimbangkan pengenalan kontrol redudansi
m. M emantau dan memperbaiki sistem operasional
57
2.1.16.
Delapan Aturan Emas Perancangan User Interface
1. Konsisten
Tampilan pola design aplikasi sebaiknya sama untuk setiap halaman
sehingga tidak membuat user bingung.
2. Shortcuts
M emberikan fungsi shortcut agar pemakai yang sering menggunakan
dapat menggunakan aplikasi lebih cepat dan mudah.
3. Umpan balik yang informative
M emberikan petunjuk kegunaan setiap icon maupun tombol.
4. Adanya penutupan (keadaan akhir)
Tersedianya aksi untuk menutup aplikasi.
5. Pencegahan kesalahan
Diberikan konfirmasi untuk setiap aksi penting yang akan dilakukan
user (misalnya proses delete) sehingga kesalahan bisa dicegah.
6. Pembalikan aksi
M enyediakan tombol untuk membatalkan aksi yang telah dilakukan.
7. Pusat kendali internal (Internal Locus of Control)
User diberikan kendali untuk menentukan langkah yang diinginkan.
8. Ingatan jangka pendek dikurangi
Icon / tombol yang digunakan sebaiknya menggunakan gambar yang
umum, agar tidak menambah beban ingatan bagi user.
58
2.1.17.
Data Flow Diagram
DFD merupakan suatu model logika data atau proses yang dibuat
untuk menggambarkan dari mana asal data dan kemana tujuan data yang
keluar dari sistem, di mana data disimpan, proses apa yang menghasilkan
data tersebut dan interaksi apa yang terdapat antara data yang tersimpan
dan proses yang dikenakan pada data tersebut.
DFD sering digunakan untuk menggambarkan suatu sistem yang
telah ada maupun sistem baru yang akan dikembangkan secara logika
tanpa mempertimbangkan lingkungan fisik di mana data tersebut
mengalir atau di mana data tersebut akan disimpan.
Gambar 2.12 Data Flow Diagram
(sumber : www.ilkom.unsri.ac.id)
59
DFD terdiri dari 3 bagian, yaitu :
1. Diagram Konteks (Context Diagram)
Diagram konteks adalah diagram yang terdiri dari suatu proses dan
menggambarkan ruang lingkup suatu sistem. Diagram konteks
merupakan level tertinggi dari DFD yang menggambarkan seluruh
input ke sistem atau output dari sistem dimana memberi gambaran
tentang keseluruhan sistem. Sistem dibatasi oleh boundary (dapat
digambarkan dengan garis putus). Dalam diagram konteks hanya ada
satu proses. Tidak boleh ada store dalam diagram konteks.
2. Diagram Nol (Zero Diagram)
Diagram nol adalah diagram yang menggambarkan proses dari data
flow
diagram.
Diagram nol memberikan
pandangan
secara
menyeluruh mengenai sistem yang ditangani, menunjukkan tentang
fungsi-fungsi utama atau proses yang ada, aliran data, dan eksternal
entity. Pada level ini sudah dimungkinkan adanya data store yang
digunakan. Untuk proses yang tidak dirinci lagi pada level
selanjutnya, symbol "*" atau "P (functional primitive) dapat
ditambahkan pada akhir nomor proses. Keseimbangan input dan
output (balancing) antara diagram 0 dengan diagram konteks harus
terpelihara.
Tujuan dari diagram nol adalah untuk “memerinci” sebuah sistem
menjadi “proses-proses” yang harus dilakukan ‘orang dalam.’ Atau
jika dibuat dalam kalimat adalah : “Apa saja proses yang harus
60
dilakukan agar mencapai sistem tersebut ?.” Jadi, diagram ini adalah
kelanjutan dari diagram konteks, yang “memperbanyak lingkaran,”
sedangkan untuk (jumlah dan isi) terminator serta (jumlah dan isi)
data flow dari dan ke terminator tersebut harus tetap.
3. Diagram Rinci (DFD Levelled)
DFD levelled menggambarkan sistem sebagai jaringan kerja antara
fungsi yang berhubungan satu sama lain dengan aliran dan
penyimpanan data, model ini hanya memodelkan sistem dari sudut
pandang fungsi.
Dalam DFD levelled akan terjadi penurunan level dimana dalam
penurunan level yang lebih rendah harus mampu merepresentasikan
proses tersebut ke dalam spesifikasi proses yang jelas. Jadi dalam
DFD levelled bisa dimulai dari DFD level 0 kemudian turun ke DFD
level 1 dan seterusnya. Setiap penurunan hanya dilakukan bila perlu.
Aliran data yang masuk dan keluar pada suatu proses di level x harus
berhubungan dengan aliran data yang masuk dan keluar pada level
x+1 yang mendefinisikan proses pada level x tersebut. Proses yang
tidak
dapat diturunkan/dirinci lagi dikatakan
fungsional dan disebut sebagai proses primitif.
primitif
secara
61
2.2. Teori Khusus
2.2.1.
Service Oriented Database Architecture (S ODA)
SODA (Service Oriented Database Architecture) adalah suatu
implementasi dari konsep pendistribusian dari basis data menggunakan
suatu servis yang dapat melakukan proses penambahan, pengubahan dan
penghapusan data secara dinamis. Basis data SODA menggunakan
konsep arsitektur informasi yang memudahkan fungsi-fungsi bisnis untuk
saling berhubungan,
misalnya untuk pertukaran
informasi oleh
departemen lain yang berkepentingan ataupun antar kantor cabang.
2.2.1.1.
Arsitektur SODA
Arsitektur SODA dapat dibagi menjadi 6 bagian:
• SODA Client
M erupakan coding (aplikasi) yang membuat koneksi pada
salah satu service yang ada dalam sistem SODA, misalnya
SODA Broker Service atau SODA Operator Service.
• SODA Broker Service
SODA Broker Service menangani semua request data yang
datang dan mendistribusikan subrequest tersebut ke dalam
SODA Operator Service. SODA Broker Service juga
menyimpan skema basis data global yang membentuk
keseluruhan skem dari basis data tersebut. Selain itu,
62
SODA Broker Service juga yang menangani eksekusi dari
SODA query.
• SODA Operator Service
Services inilah yang mengatur proses pertukaran data, dari
dan ke basis data. Pertukaran data dilakukan dengan proses
pipelining. Service proses ini terbagi menjadi 3 yakni:
– Data Service
– Operator Service
– Storage Service
• Data Sources
M erupakan basis data yang digunakan.
2.2.1.2.
Layer pada S ODA
Gambar 2.13 Layer S ODA
Layer pertama berisi semua semua raw data sources.
Setiap data source diakses paling sedikit oleh satu SODA Data
Operator Service di layer kedua.
63
Layer kedua berisi semua SODA Data Operator
Service. Layer ini mengubah data yang disimpan dalam basis
data menjadi format WRS SODA, serta membentuk interface
antara data source dengan SODA Operator Service untuk
dapat memanipulasi data. Sebuah SODA Data Operator
Service hanya dapat terhubung dengan satu data source, yang
akan membaca keseluruhan tabel beserta isinya.
Layer ketiga berisi semua SODA Operator Service
kecuali Data dan Storage yang dapat menerapkan manipulasi
data. SODA Operator Service dapat menukar data satu sama
lain dengan menggunakan mekanisme notifikasi.
Hasil dari pertukaran data tersebut akan selalu
disimpan pada SODA Storage Service yang berada pada layer
keempat.
Lalu pada layer berikutnya terdapat SODA Broker
Service yang menangani exception handling messages. SODA
Broker Service ini menjadi middleware antara SODA client
dan SODA Storage Service, serta mengatur eksekusi quesry
dan bereaksi pada error.
SODA Client ditempatkan pada layer teratas sehingga
dapat memasukkan query, sementara hasilnya selalu disimpan
pada SODA Storage Service.
64
2.2.1.3.
Communication Cycle
a. SODA client memasukkan query ke dalam SODA Broker
Service.
b. SODA Broker Service menganalisa query dan memberi
tugas kepada SODA Operator Service termasuk Data
Operator dan Storage Operator Service.
c. Semua SODA operator Service segera bekerja begitu
menerima data. SODA Data Operator Service segera
mengirim data.
d. Data disimpan dalam SODA Storage Operator Service
sampai data diambil oleh SODA client.
2.2.1.4.
Mekanisme Dasar SODA
Berikut ini contoh dari mekanisme dasar SODA :
•
Client akan mengirimkan suatu query ke SODA Broker
Service. Di dalam SODA Broker Service, akan dilakukan
pengecekan terhadap query tersebut. Pertama dilakukan
pengecekan sintaksis, jika terjadi kesalahan, maka query
akan
ditolak
oleh
Broker.
Selanjutnya
dilakukan
pengecekan tabel dan atribut dari query yang dikirim
dengan Global Database Schema. Jika terjadi kesalahan,
misalnya ada atribut atau tabel yang tidak sesuai, maka
query tidak dapat dijalankan karena data tidak sesuai.
65
Gambar 2.14 Client - Broker
•
SODA akan membuat suatu execution tree untuk
menentukan urutan pengerjaan dari operasi-operasi query
yang masuk. Setiap operasi akan ditangani oleh minimal
satu SODA Operator Service. Jika ada SODA Operator
service yang hilang, maka pengerjaan/eksekusi query akan
dihentikan di sini.
Gambar 2.15 Broker - SODA
•
Setelah Execution Tree terbentuk, maka setiap SODA
Operator Services akan menerima Subrequest yang
merupakan
bagiannya.
Jadi
setiap
Operator
akan
mengerjakan bagiannya sendiri. Tapi tidak menutup
kemungkinan bahwa setiap operator saling berhubungan
untuk mengerjakan suatu request.
66
Gambar 2.16 Broker - Operator
•
Setelah semua request selesai dikerjakan oleh Broker
Service, hasil kerjanya akan disimpan di root node,
sehingga ketika client meminta hasilnya, client tinggal
mengambil dari root node.
Gambar 2.17 Client – Operator
2.2.1.5.
Kelebihan SODA
•
SODA dapat melakukan proses pengiriman data dalam
bentuk messaging secara dinamis
•
SODA terintegrasi dengan database itu sendiri sehingga
proses keamanan dan integrasi data menjadi lebih terjamin
67
•
SODA memiliki web service sehingga SODA dapat
menjadi HOST dan tidak memerlukan tools lain.
2.2.1.6.
SOAP (Simple Object Access Protocol)
SOAP merupakan protokol yang dispesifikasikan
untuk pertukaran struktur informasi menggunakan web service
dalam jaringan komputer. Protokol ini bergantung pada XM L
sebagai format dari pesannya dan juga pada protokol layer
aplikasi lain.
Komunikasi antara 6 bagian berbeda dalam arsitektur
SODA menggunakan pesan SOAP:
Gambar 2.18 Komunikasi - SOAP
Kelebihan SOAP :
68
• M engunakan SOAP melalui HTTP membuat komunikasi
melalui proxy dan firewall lebih mudah dibandingkan
dengan teknologi eksekusi remote.
• SOAP dapat digunakan dengan protokol transport berbeda,
meskipun standar yang digunakan adalah HTTP.
• SOAP dapat digunakan di berbagai platform, simple dan
extensible.
Kekurangan SOAP :
•
Hanya dapat menggunakan format XM L, sehingga
proses pengiriman lebih lambat
•
Ketika
menggunakan
HTTP
sebagai
protokol
transport, hanya satu client yang dapat menggunakan
service ini.
2.2.2.
Distributed DBMS
2.2.2.1.
Konsep Arsitektur Distributed Database
Distributed database merupakan koleksi data – data
yang saling berhubungan ( dan deskripsi dari data – data
tersebut ) dan tersebar secara fisik melalui jaringan komputer.
Distributed
System)
adalah
DBM S
software
(DataBase
system
Management
yang
mengatur
pendistribusian basis data dan membuat sistem terdistribusi
yang jelas kepada user. DDBM S ini merupakan satu kesatuan
69
basis data logic yang tersebar dalam fragment pada masing –
masing komputer yang terpisah, namun dikendalikan oleh
suatu DBM S yang sama. Setiap komputer dapat secara
independent mengatur basis datanya sendiri, dan juga
memungkinkan untuk mengakses basis data pada komputer
lain dengan otonomi tertentu.
Karakteristik DDBM S :
ƒ Kumpulan data – data yang tersebar dan terhubung
secara logical
ƒ Data – data terbagi – bagi ke dalam fragment –
fragment
ƒ Fragment – fragment dapat di replikasi
ƒ Fragment di alokasikan ke bagian – bagian alin
ƒ Semua bagian – bagian terhubung dengan jaringan.
ƒ Data pada setiap site dikendalikan oleh DBM S
ƒ Setiap DBM S pasti memiliki minimal satu aplikasi
global
Distributed
Processing
merupakan
centralized
database yang bisa diakses melalui jaringan komputer.
M emiliki sebuah pusat database dan semua site mengaksesnya
melalui jaringan. Sedangkan Parallel DBM S (Tambahan )
merupakan DBM S yang dijalankan pada berbagai processor
70
yang di design untuk dapat mengakses beberapa basis data
secara bersamaan untuk meningkatkan performa.
2.2.2.2.
Keuntungan dan Kerugian DDBMS
Keuntungan :
ƒ Reflects Organizational Structure
Karena tersebar di seluruh bagian dari organisasi, DDBM S
dapat dengan lebih jelas menggambarkan keadaan dari
sebuah organisasi.
ƒ Improved shareability and local autonomy
Dengan adanya database di setiap bagian, maka setiap
lokal basis data dapat mengakses basis datanya sendiri
secara penuh(local autonomy). Namun tidak menutup
kemungkinan untuk pusat mengakses basis data pada
bagian tertentu. (shareability)
ƒ Improved Availability
Pada centralized DBM S, ketika satu komputer pusat
terjadi gangguan pada DBM Snya, maka seluruh bagian
dari DBM S akan terhenti. Tetapi pada distributed DBM S
ini, kerusakan pada satu site tidak berpengaruh pada site –
site yang lain. Walaupun kerusakan terjadi di pusat, namun
proses untuk perbaikannya akan menjadi lebih mudah.
ƒ Improved Reliability
71
Karena data tersimpan di beberapa site, maka tingkat
kepercayaan pada suatu data akan meningkat, jika data
tersebut memang benar ada di beberapa site. M isalnya di
site A, seorang customer memiliki sebuah aset mobil
sebagai jaminan kredit, begitu pula di site B, maka berarti
customer tersebut data – datanya benar.
ƒ Improved Performance
Karena data tersimpan di tempat yang terdekat dengan
bagian yang sering mengakses data tersebut, maka proses
pengaksesan basis data tentu akan lebih cepat.
ƒ Modular growth
Semakin lama, database semakin berkembang, namun
belum tentu perkembangan basis data di semua site sama.
Jadi dengan DDBM S, pertumbuhan berbeda – beda di
setiap bagian / site dapat dilakukan.
Kerugian:
ƒ Complexity
Proses
untuk
mendistribusikannya
memerlukan
pertimbangan dalam hal performance, reliability dan
availability. Hal ini memerlukan perancangan yang lebih
kompleks dibandingkan dengan centralized basis data.
ƒ Costly
72
Karena lebih kompleks, maka maintenance terhadap
DDBM S akan memakan lebih banyak biaya.
ƒ Security
Pengontrolan terhadap akses basis data lebih sulit, karena
selain harus mengamankan jaringan komputer yang ada,
basis data di semua site juga harus aman.
ƒ Integrity control more difficult
Database
integrity
merujuk
kepada
validitas
dan
konsistensi dari data yang disimpan. Antara basis data
yang satu dengan yang lain harus memiliki data yang
sesuai, terutama antara data yang tersebar dengan data
pusat. Itu sebabnya proses pengintegrasian menjadi lebih
sulit sebab harus punya memiliki contraint khusus yang
didefinisikan untuk seluruh basis data.
ƒ Lack of standards
Tidak adanya standar khusus yang mengatur tentang
DDBM S, juga tidak
membantu
user
ada metodologi khusus yang
mengubah
centralized
DBM S
ke
distributed DBM S.
ƒ Lack of experience
Teknologi ini masih terbatas dan lebih jarang digunakan
dibandingkan dengan centralized DBM S.
ƒ Database design more complex
73
Perancangan
basis
data
harus
memperhitungkan
fragmentasi data, alokasi fragment – fragment ke site – site
tertentu dan replikasi data. Hal ini membuat proses
perancangan basis data menjadi lebih sulit dan kompleks.
2.2.2.3.
Fungsi dari DDBMS
DDBM S yang baik memiliki fungsi berikut ini :
ƒ M eningkatkan
communication
untuk
services
menyediakan akses data ke lokal dan memungkinkan
untuk proses transfer query dan data melalui jaringan.
ƒ M emperluas sistem katalog untuk menyimpan detail dari
distribusi data.
ƒ Dapat melakukan query secara terdistribusi, termasuk
query optimization dan remote data access.
ƒ M emperluas security control untuk membuat autorisasi
terhadap akses basis data.
ƒ M emperluas
concurrency
control
untuk
menjamin
konsistensi data terdistribusi
ƒ M eningkatkan fungsi recovery service untuk kasus – kasus
dimana terjadi kegagalan di salah satu site basis data.
2.2.2.4.
Arsitektur Umum
Terdapat 3 bagian arsitektur DDBM S:
74
ƒ Global conceptual schema
merupakan deskripsi keseluruhan dari distributed database
yang akan dibuat. Pertama – tama dibuat tidak seperti akan
didistribusikan. Level ini disetarakan dengan conceptual
level seperti ANSI-SPARC architecture, mengandung
definisi dari entity, relationship, constraint, security dan
integrity.
ƒ Fragmentation dan alokasi schema
M erupakan deskripsi bagaimana data – data tersebut
dibagi – bagi secara logical.
ƒ Local schema
M erupakan perancangan skema di masing - masing bagian
basis data.
2.2.2.5.
Komponen Arsitektur DDBMS
Terdiri dari 4 macam :
ƒ Local DBMS Component
DBM S yang dibutuhkan untuk mengatur data di lokal
ƒ Data communications Component
DC
component
memungkinkan
berhubungan.
ƒ Global System Catalog
semua
site
saling
75
M enyimpan informasi dari keseluruhan proses yang
terjadi, komunikasi yang terjadi, dan data apa saja yang
melewati jaringan.
ƒ Distributed DBMS Component
M engontrol keseluruhan basis data yang tersebar di
berbagai tempat.
2.2.2.6.
Alokasi Data
Ada 4 tipe alokasi data, yaitu :
ƒ Centralized
Basis data tersimpan di satu pusat, dimana akan
menyebabkan komunikasi data antar jaringan tinggi yang
dapat mengakibatkan terhentinya seluruh proses ketika
pusat mengalami kerusakan.
ƒ Fragmented ( partitioned )
Setiap basis data tertentu disimpan di masing – masing
sitenya. M isalnya data customer di tempatkan di site A,
data karyawan di site B. Jika salah satu site mengalami
kerusakan, maka hanya data tersebut yang rusak, data di
site lain masih tetap ada.
ƒ Complete Replication
M enempatkan complete copy di semua site basis data,
sehingga reliability dan availability menjadi maksimal. Di
76
sini semua data di semua tempat memiliki data yang sama.
Jika salah satu tempat terjadi kerusakan, bisa langsung
diperbaiki.
ƒ Selective Replication
Gabungan dari complete replication dan fragmented,
dimana data yang disimpan di semua tempat bukan
merupakan data yang sama, melainkan data dari tempat itu
sendiri. M isalnya data customer di site A adalah semua
data customer yang berada di A, sedangkan di site B juga
terdapat data customernya sendiri. Fungsi basis data pusat
pada alokasi data tipe ini ialah untuk mengkoordinir setiap
basus data sitenya. Alokasi data ini paling banyak
digunakan karena fleksibilitasnya.
2.2.3.
Service Broker
2.2.3.1.
Pengertian Service Broker
SQL
Service Broker
(SSB)
merupakan
sebuah
teknologi baru yang memungkinkan proses internal maupun
ekternal untuk mengirim, memproses dan menerima pesan.
SSB ini dibangun pertama kali dalam mesin SQL Server 2005
yang memungkinkan proses pengiriman pesan terjadi dalam
server maupun antar server. Proses messaging ini dapat
dicapai dengan menggunakan extension T-SQL. Jadi dalam
77
perancangan sistem basis data SODA ini, layanan dari SSB
berguna untuk mengatur proses pengiriman dan penerimaan
data antar basis data lokal dan basis data pusat.
4 sifat dari SSB :
o
Asinkronus
Pesan data dikirim satu per satu, tidak dijalankan
secara bersamaan
o
Ordered
Pesan data yang dikirim ataupun diterima selalu
sesuai dengan urutan pengiriman sehingga data mudah
diatur
o
Reliable
Karena terintegrasi dengan basis data, maka proses
pengiriman pesan data lebih terjamin (pasti sampai pada
basis data yang diinginkan)
o
Durable
Jika pesan yang dikirim berhasil maupun gagal,
hasilnya pasti akan tetap tercatat pada system failure,
sehingga mudah dilacak.
Dalam proses pengiriman data antar basis data yang
terjadi sekarang ini, dilakukan dengan langsung mengirimkan
data ke basis data tujuan, tanpa adanya konsep queue
(antrian). Hal ini sering menimbulkan permasalahan sebab
78
pada waktu yang bersamaan, mungkin terjadi lebih dari satu
proses pengiriman data kepada satu basis data tertentu. Hal ini
bisa menyebabkan clash antar data yang dikirim, sehingga
proses pengiriman tersebut gagal. Konsep messaging dengan
queue memungkinkan proses pengiriman berjalan secara
teratur sesuai urutan, dan tidak akan terjadi tabrakan antara
data yang satu dengan yang lain jika terjadi banyak
pengiriman dalam satu waktu yang bersamaan. Dalam hal ini
konsep messaging menciptakan fleksibilitas dalam beban
pekerjaan, dimana dapat diartikan ke dalam kapasitas
(scalability) yang besar dan performa dari sistem.
Penggunaan messaging juga dapat menyediakan
kemampuan untuk meningkatkan proses paralel (dua proses
pengiriman yang dijalankan secara bersamaan namun tidak
mengganggu proses satu sama lain), yang sangat diperlukan
dalam pembuatan sistem basis data SODA.
2.2.3.2.
Konsep dasar SQL service Broker (SS B)
1. Queue
Konsep antrian ini digunakan untuk menyediakan ikatan
antara pengirim dengan
penerima. Pengirim cukup
menaruh pesan pada antrian dan berlanjut dengan aplikasi.
79
Tugas pengiriman ini akan dilakukan secara otomatis oleh
SQL Service broker kepada tujuan yang sesuai.
2. Dialog
Sebuah dialog merupakan sebuah conversation antara dua
Service Broker
yang menetapkan initiator
service
(pengirim), target service (penerima) dan contract yang
akan digunakan untuk conversation. Message dalam
dialog akan dikirim sesuai urutan dalam 2 arah antar 2
basis data ataupun queue. Urutan ini akan dijaga sepanjang
transaksi, input thread, output thread, system crash dan
restart.
Lebih lanjut, dialog juga akan menetapkan
encrytion option dan lifetime untuk sebuah conversation.
Pada saat SSB menerima sebuah message untuk dialog,
SSB akan menempatkan message tersebut ke dalam queue
untuk dialog. Aplikasi menerima message dari queue dan
memprosesnya. Dengan penggunaan SSB, setiap message
memiliki handle yang secara unik mengidentifikasi dialog
yang berhubungan dengannya. Handle ini pada dasarnya
merupakan kunci, yang memegang transaksi sampai
proses tersebut commit (selesai) untuk setiap dialog.
3. Conversation Group
M erupakan kumpulan dialog conversation yang saling
berhubungan. SSB menyediakan lock pada conversation
80
group untuk pengadaan fungsionalitas Exactly-Once-InOrder (EOID). Fungsionalitas ini membolehkan message
dari conversation group yang sama untuk diterima secara
terurut. Dengan demikian, hanya satu session pada suatu
waktu bisa menerima message untuk conversation group.
Karena conversation group bisa memiliki lebih dari satu
conversation,
sebuah
aplikasi
dapat
menggunakan
conversation group untuk mengenali message yang
berhubungan dengan business task yang sama dan
memproses messages tersebut bersamaan.
M isalnya saja, dalam contoh e-commerce, semua dialog
yang
digunakan
untuk
memproses
satu
order
dikelompokkan menjadi satu. Jadi conversation group
merupakan unique identifier yang terdapat dalam setiap
message
yang
berkaitan
dengan
order
tersebut.
Penggunaan umum conversation group ialah sebagai alat
untuk menyediakan label mengenai keadaan/status proses
tertentu. M isalnya saja, satu proses A baru dapat
dijalankan jika proses B dan C sudah selesai, maka
conversation group dan status akan disimpan dalam basis
data sampai terjadi message berikutnya dan perubahan
status yang berkaitan dengan order tersebut.
4. Activation
81
SSB menyediakan layanan yang memungkinkan user
untuk menunjuk suatu stored procedure (SP) untuk
menangani message pada layanan tertentu. Ketika message
pertama kali tiba, maka SSB akan mengecek apakah ada
SP yang sedang berjalan untuk memproses message
tersebut. Jika tidak ada, maka akan diaktifkan secara
otomatis. SP ini akan aktif sampai queue kosong.
5. End Point
SQL Server
2005
menggunakan end
point untuk
berkomunikasi dengan Service Broker pada SQL Server
instance yang berbeda. Sebuah end point mengizinkan
Service Broker untuk berkomunikasi antar network dengan
menggunakan protokol transport seperti HTTP, TCP, dan
SOAP (Simple Object Access Protocol). Sebuah end point
untuk
setiap
protokol
transport
harus
ditetapkan
menggunakan transaction-SQL DDL. Namun secara
default, SQL Server tidak memiliki end point, dan oleh
karena itu harus dibuat terlebih dahulu sehingga dapat
digunakan untuk berkomunikasi.
6. Message Transport
Sebuah message adalah entity yang ditukar antar Service
Broker. Sebuah message harus memiliki nama dan tipe
data. Selain itu sebuah message bisa memiliki validation
82
pada tipe data dan merupakan bagian dari sebuah
conversation yang memiliki sebuah unique identifier
(pengenal khusus) dan unique sequence number untuk
menyelenggarakan message ordering.
Pengiriman message diatur oleh 2 protocol yang mirip
dengan TCP/IP dan FTP. Protocol pertama ialah Binary
Adjacent Broker (BAB) yang merupakan interface TCP/IP
penyedia transport message dasar. BAB merupakan
protocol yang multiplexed dan 2 arah yang dapat
menangani transport message untuk dialog SSB yang
banyak. Sedangkan untuk proses ordering message dan
confirming delivery dilakukan oleh protocol kedua, yakni
Dialog Protokol. Protokol ini menangani hubungan antar
endpoint dalam pengiriman pesan serta menangani proses
ordering dan status terkirimnya pesan atau tidak. Jadi
protokol kedua ini lebih berfokus pada komunikasi
delivery failure dan bertanggung jawab untuk message
security.
2.2.3.3.
Entitas Utama dalam SQL Service Broker
Service Broker terdiri dari 6 entitas utama yang
terdapat dalam setiap basis data:
•
M essage Types
83
M enjelaskan nama, tipe dan validasi untuk setiap message
•
Contracts
Contract merupakan perjanjian antara dua service yang
menggambarkan apa tipe message yang dimiliki oleh
sebuah
message
dan
siapa
yang
berhak
untuk
mengirimkan message tersebut. Sebagai contoh anda dapat
menetapkan multiple message type di dalam sebuah
contract dan menetapkan apakah sender atau receiver
yang diijinkan untuk mengirim message tersebut. Terdapat
3 jenis tipe contract :
o Initiator
Hanya initiator end point yang dapat mengirimkan
message dari specified
message type.
Initiator
merupakan end point yang memulai conversation.
o Target
Hanya target end point yang dapat mengirimkan
message dari specified message type. Target adalah
end point yang menerima conversation dari initiator.
o Any
Kedua end point dapat mengirimkan message dari
specified message type. Anda harus membuat identical
contract object pada kedua lokal dan server basis data.
•
Queues
84
Queue adalah tempat penyimpanan utama untuk message
yang akan dikirim antar dua service. M essage bisa
disimpan di dalam local queue jika service server tidak
dapat menyimpan message tersebut. SSB akan mencoba
untuk mengirimkan kembali message dan menghapus
message tersebut di dalam local queue pada saat message
berhasil dipindahkan ke dalam server. Lebih lanjut, queue
dapat diasosiasikan dengan lebih dari satu service, dan
menyediakan sebuah activation mechanism. Activation
mechanism memperbolehkan SP untuk dipanggil dalam
menangani message. Ini dapat dilihat seperti pipeline
untuk sebuah message. Sebuah queue harus diatur untuk
dapat mengaktifkan SP, mengirim dan menerima message.
•
Services
Service digunakan oleh SSB untuk mengirimkan message
ke queue yang tepat di dalam basis data, mengarahkan
message, menjalankan contract pada sebuah conversation,
dan menentukan remote security untuk conversation baru.
Ada 2 macam services pada SSB:
o Service program
Service ini memproses message dan menyediakan
logika dari service sehingga dapat secara otomatis
mengaktifkan service program pada saat setiap
85
message tiba. Cara lainnya, anda dapat membuat
jadwal event untuk mengaktifkan service program,
atau anda dapat menjalankannya secara manual.
Service ini akan sering dibutuhkan untuk mengirim
sebuah tanggapan message kepada initiator dari
conversation untuk menyelesaikan tugas. Tanggapan
ini akan menjadi bagian dari conversation yang sama
sehingga initiator dapat menerima tanggapan yang
tepat.
o Service object
Service ini menampilkan end point yang memiliki
alamat dari sebuah service. Service object akan
menentukan nama dari queue yang akan menyimpan
message dan untuk dimana contract dari service ini.
Jika service tidak menetapkan sebuah contract, service
hanya dapat memulai conversation dan tidak dapat
menjadi server.
•
Routes
SSB menggunakan route (rute) untuk menentukan kemana
sebuah pesan akan dikirim. Ini dapat digunakan untuk
distributed
messaging
di
dalam
SSB
yang
memperbolehkan remote dan local instance untuk saling
berkomunikasi.
Pada
saat
membuat
route,
anda
86
menentukan service, IP address dan protokolnya. Secara
default, setiap basis data memiliki AutoCreatedLocal route
yang digunakan untuk menentukan local instance dari
basis data.
•
Remote Service Binding
M embuat sebuah binding yang menentukan security
credential untuk digunakan untuk memulai sebuah
conversation dengan remote service.
2.2.3.4.
Pentingnya messaging dalam basis data SODA
Biasanya
suatu
aplikasi
mengalami
banyak
permasalahan yang berkaitan dengan basis data, misalnya:
•
urutan messaging
•
konsistensi daripada transaksi
•
kompleksitas data
•
aplikasi yang digunakan tidak terlibat dalam pengaturan
basis data
SSB dapat mengatasi semua permasalahan tersebut.
Urutan messaging yang sering menjadi kendala, ditangani
oleh SSB dengan mengatur urutan message sesuai urutan
pengirimannya. Koordinasi message ditangani oleh dialog
identifier dan conversation group yang membuatnya mudah
untuk menentukan urutan. Dalam SSB, multithreading
87
menjadi mudah sebab adanya penggunaan lock khusus yang
mencegah thread lain menerima message yang berkaitan
sampai sebuat transaksi commit (selesai). Hal ini dapat
mencegah
masalah
breaking
referential
integrity
(penghapusan/pengubahan record yang mengandung primary
key yang merupakan foreign key pada suatu table lain).
Sehingga pada saat melakukan proses sinkronisasi, meskipun
terdapat banyak data yang dikirim secara bersamaan,
keamanan data tersebut akan tetap terjaga.
Pada saat message diterima dalam queue, SSB akan
menanganinya
permasalahan
secara
otomatis
administratif
dan
menghilangkan
seperti memutuskan
berapa
banyak entitas messaging yang dibutuhkan. SSB terlibat
langsung dengan fitur manajemen basis data yakni SP, XM L,
Web Services, disk storage dan backup policy. SSB dapat
menerima message dari sistem di luar basis data seperti
merchant gateway (contoh: PayPal) yang memroses kartu
kredit melalui panggilan HTTPS. Pada sistem basis data
SODA ini, SSB dapat mengatur SP mana yang akan
dieksekusi dalam melakukan proses sinkronisasi, duplikasi
data, pengiriman dan penerimaan.
SSB juga mendukung proses messaging transaksi.
Istilah transaksi disini merupakan hal yang sama dalam
88
penggunaan basis data, yakni sekumpulan perintah yang
diperlakukan sebagai suatu atomic event. Jika sebuah transaksi
gagal, maka message yang dikirim dan diterima akan di-rolled
back
(kembali
ke
kondisi
awal)
dan
tidak
terjadi
akibat/perubahan apapun sampai transaksi tersebut commit
(selesai). Jadi messaging ini meningkatkan kemudahan dari
pembuatan program aplikasi message. User dapat dengan
bebas memisahkan perintah pengiriman dan penerimaan
kapanpun user menginginkannya. Jika transaksi tersebut
mengalami roll back, maka pesan transaksi akan kembali ke
barisan queue sehingga message tersebut dapat diterima dan
diproses kembali. Proses seperti inilah yang diterapkan pada
perancangan sistem basis data dan aplikasi PT BFI Finance
Indonesia Tbk. Jikalau terjadi gangguan pada saat proses
pengiriman ataupun penerimaan berlangsung, maka hasil basis
data akan dikembalikan ke kondisi semula jika keseluruhan
proses belum commit. Hal ini akan menjaga keakurasian
informasi pada basis data.
2.2.3.5.
Penggunaan SQL Service Broker
Di bawah ini merupakan daftar dari penggunaan SQL
Service Broker yang dapat diterapkan pada aplikasi:
•
Trigger yang asinkronus
89
Banyak aplikasi yang menggunakan trigger, seperti online
transaction processing (OLTP) systems. Sebuah trigger
akan membuat antrian message yang direquest service
yang bekerja dari sebuah SSB. Program yang menerapkan
service menampilkan pekerjaan pada transaksi yang
terpisah. Dengan menampilkan pekerjaan dalam transaksi
yang terpisah, transaksi awal dapat dikerjakan dengan
segera. Aplikasi menghindari sistem slowdown yang
dihasilkan dari membiarkan transaksi awal terbuka pada
saat menampilkan pekerjaannya. Jadi trigger pada aplikasi
ini memungkinkan pengerjaan data dilakukan satu per satu
berdasarkan antrian dengan pemrosesan yang efisien.
•
Pemrosesan Reliable Query
Kebanyakan aplikasi saat ini menuntut pemrosesan queryquery yang dapat diandalkan, tanpa interupsi dari
computer failure, power outages, dan lain-lain. Aplikasi
ini membutuhkan pemrosesan reliable query yang dapat
menjalankan query dengan mengirimkan message kepada
SSB. Aplikasi akan menerapkan service akan membaca
message,
menjalankan
query,
dan
mengembalikan
hasilnya. Semua operasi tersebut dilakukan dengan
mengeksekusi SP yang berisi reliable query. Jika
kegagalan terjadi, maka seluruh transaksi akan roll back
90
dan message akan dikembalikan ke queue. Pada saat
kondisi komputer pulih, aplikasi akan memulai kembali
dan memproses message lagi.
•
Pengumpulan data
Sistem basis data SODA ini dibuat memang bertujuan
untuk mengumpulkan data dari basis data lokal ke basis
data pusat. Dengan menggunakan SSB, maka proses
pengumpulan data yang reliable dapat dilakukan. Untuk
perusahaan yang memiliki banyak cabang seperti PT BFI
Finance, SSB akan digunakan untuk mengirimkan
informasi mengenai transaksi ke basis data pusat. Karena
SSB menyediakan message delivery yang asinkron dan
reliable,
setiap
cabang
dapat
melanjutkan
untuk
memproses transaksi meskipun jika cabang kehilangan
hubungan secara sementara dengan basis data pusat. SSB
security membantu untuk meyakinkan bahwa message
tidak salah arah dan membantu untuk melindungi data
selama transit.
•
Pemrosesan Distributed Server-Side untuk aplikasi klien
Aplikasi yang mengakses multiple SQL Server database
untuk informasi merupakan aplikasi yang cocok untuk
menggunakan Service Broker. Web-based application ini
dapat menggunakan
SSB pada sisi server
untuk
91
pertukaran informasi antar basis data yang berbeda yang
mengandung data customer, finance, dan credit. SSB
menyediakan message queuing dan reliable message
delivery sehingga aplikasi ini dapat melanjutkan untuk
memasukkan transaksi meskipun salah satu dari basis
data tidak dapat diakses atau heavily loaded. Dalam
contoh ini, SSB berfungsi sebagai framework untuk
distributed OLTP system.
•
Konsolidasi data untuk aplikasi klien
Aplikasi ini dapat menampilkan
informasi secara
simultan dari multiple basis data dengan menggunakan
layanan dari SSB. Aplikasi ini dapat menggabungkan
data dari multiple location ke dalam sebuah layar dapat
menggunakan SSB untuk menjalankan multiple request
secara pararel (daripada secara serial) dan secara
signifikan mengurangi waktu respon aplikasi tersebut.
•
Pemrosesan Large-Scale Batch
Aplikasi yang harus menampilkan pemrosesan large-scale
batch dapat mengambil manfaat dari queuing dan parallel
processing yang ditawarkan oleh SSB untuk menangani
pekerjaan dalam jumlah besar secara cepat dan efisien.
Aplikasi akan menyimpan data untuk diproses di dalam
92
SSB queue. Sebuah program, secara periodik, akan
membaca dari queue dan memproses data tersebut.
2.2.3.6.
Cara Kerja SQL Service Broker
Berikut merupakan proses kerja SSB dalam proses
messaging:
1. Pada awalnya, kedua SSB yang akan saling mengirimkan
data, harus memiliki komponen dasar untuk melakukan
proses messaging. Komponen-komponen tersebut:
•
Services
•
Contracts
•
M essages
•
Queues
•
Routes antar kedua SSB
•
Dialog Security Certificate
•
Transport Security Certificate
•
Remote Service Bindings
•
End Point
2. Pada saat SSB A (sender) memulai mengirimkan data,
maka sebuah conversation akan dimulai. Message yang
berisi data dalam format XM L akan dikirim sebagai
message type khusus kepada queue tertentu. SSB akan
93
mengecek rute pengiriman, apakah data sudah dikirim
pada komputer dan basis data yang sesuai.
3. Message ini kemudian ditampung pada queue, yang akan
dijalankan sesuai dengan urutan pengiriman message.
4. Lalu queue ini akan diterima oleh SSB B (receiver) untuk
kemudian diproses. Pada sistem basis data SODA ini, akan
dilakukan duplicate checking antar data yang diterima
dengan data yang berada pada basis data pusat (SSB B).
Hanya data baru dan data yang mengalami perubahan
yang akan diproses. Keseluruhan proses ini dilakukan
dengan mengeksekusi SP yang berisi T-SQL query untuk
melakukan pengecekan maupun duplikasi data.
5. Jika terjadi gangguan pada saat proses pengiriman maupun
penerimaan, maka proses tersebut akan di-roll back
sehingga tidak terjadi perubahan apapun dalam basis data.
Message akan kembali lagi ke queue untuk diproses
kemudian.
6. Jika komunikasi lancar dan selesai, maka conversation
pun berakhir dan perubahan pada basis data pusat sudah
dapat dilihat hasilnya.
94
Gambar 2.19 S ervice Broker Database
Gambar 2.20 S ervice Broker
2.2.3.7.
SQL Service Broker Security
SSB memiliki kebutuhan keamanan seperti halnya
aplikasi database lain.
komunikasi
dimana
M odel SSB
SSB
mengikuti model
menggunakan
fungsionalitas
95
certificate yang ditemukan dalam SQL SERVER 2005. SSB
memiliki 2 tipe keamanan:
1. Dialog security
Keamanan ini mengenkripsikan message dalam individual
dialog dan memverifikasi identitas dari peserta dalam
dialog. Tipe keamanan ini juga menyediakan remote
authorization dan message integrity checking. Jadi dialog
security membangun komunikasi yang sudah terenkripsi
dan terautentifikasi antar dua service.
Dialog security bisa diterapkan dengan dua cara:
•
Full dialog security
Untuk Full dialog security, basis data yang memulai
sebuah conversation dan basis data yang menerapkan
service. Setiap service di dalam conversation harus
memiliki sebuah remote service binding yang akan
memetakan user account untuk remote basis data user
ke
remote
service.
Sebuah
certificate
harus
digabungkan dengan setiap user, sehingga message
tersebut dapat dienkripsi menggunakan public key
milik penerima dan didekripsi kembali menggunakan
private key yang cocok.
•
Anonymous dialog security
96
Anonymous dialog security bekerja dengan cara yang
sama dengan full dialog security, tetapi target service
tidak membutuhkan akses/izin secara eksplisit ke
remote user. Pada saat anonymous dialog security
digunakan, target service membolehkan akses melalui
sebuah guest account, sehingga sebuah session key
dihasilkan dan dapat digunakan untuk mengenkripsi
pertukaran message oleh service.
2. Transport Security
Keamanan ini digunakan untuk mencegah basis data yang
tidak berkaitan untuk mengirimkan message ke dalam
basis data dalam local instance sehingga terbentuklah
sebuah koneksi yang terbukti aman antara dua service
yang saling terikat dalam sebuah conversation. Services
saling berkomunikasi dengan mengirimkan message ke
sebuah HTTP end point pada remote server (dibuat
menggunakan
CREATE
ENDPOINT
transact-SQL
statement). Jadi, transport security membangun koneksi
jaringan yang terautentifikasi antar 2 database.
SSB menggunakan certificate untuk mengautentifikasi
komunikasi antara lokal dan remote server. Certificate
akan menyediakan mekanisme terpercaya yang akan
memetakan
user
dalam
skema
yang
mengandung
97
fungsionalitas untuk instance SSB. Keuntungan daripada
certificate ialah tidak menciptakan masalah kepemilikan
berantai.
SSB bukanlah solusi bagi masalah performa yang terkait
dengan scalability (daya tampung/kapasitas) aplikasi.
Namun, SSB dapat menjadi solusi bagi aplikasi yang
mengalami
kesulitan
dalam
proses
bisnis,
seperti
keharusan menunggu sistem lain untuk merespon.
2.2.3.8.
Penggunaan Stored Procedure (S P)
SP merupakan function yang berisi syntax query untuk
mengakses basis data. Awalnya, pada saat mengembangkan
web application, syntax query dapat langsung ditempatkan
pada halaman web. Namun seiring dengan munculnya
berbagai
permasalahan
keamanan
dan
meningkatnya
kebutuhan, maka digunakanlah SP yang dapat mengatasi
permasalahan dan memenuhi kebutuhan tersebut. Itulah
sebabnya dalam pembuatan SSB connection, semuanya
dilakukan dengan pembuatan SP untuk setiap fungsi.
98
2.2.3.9.
Keuntungan penggunaan Store Procedu re
1. Security
Tanpa SP, maka syntax query akan langsung diletakkan
pada halaman web. Hal ini akan riskan jika source code
yang berisi syntax query dapat dilihat oleh orang lain.
Dengan penggunaan SP, web application akan lebih aman
karena syntax query diletakkan di dalam database (pada
halaman web hanya mengakses fungsi saja), sehingga
syntax tidak dapat dilihat oleh user. Dengan demikian,
kecil kemungkinan bagi user tersebut untuk dapat
mengakses maupun memodifikasi basis data.
2. Bandwith
Tanpa SP, setiap kali pengaksesan data ke dalam basis
data, user harus me-load semua table yang berkaitan
beserta atributnya. Hal ini akan menyebabkan waktu
pengaksesan yang lama, terlebih jika data tersebut
jumlahnya banyak dan tidak sedikit
user yang sedang
mengaksesnya.
Dengan menggunakan SP, user cukup mengirimkan
parameter yang dibutuhkan, lalu menerima kembali value
yang diinginkan, tanpa mengulangi proses loading table
setiap kali data diakses. Hal ini akan mengurang beban
99
bandwith yang akan menambah kecepatan pada saat
pengaksesan data.
Tentunya hal ini akan memberikan kenyamanan bagi user
(dapat mengakses data yang dibutuhkan dalam waktu yang
singkat) dan juga bagi perusahaan penyedia layanan web
(menghemat biaya bandwith yang cukup mahal).
3. Reusable
Dalam setiap web application project, umumnya akan
terdapat modul dan fitur yang sama, misalnya saja
LOGIN. Jika pada Project A sudah terdapat SP untuk
proses LOGIN tersebut, maka pada Project lain yang
menggunakan database yang sama, dapat langsung
memakai SP tersebut tanpa harus dibuat ulang. Hal ini
akan menghemat waktu dan tenaga dalam pengerjaan
project.
4. Maintenance
Dengan penggunaan SP, tentunya fungsi-fungsi yang
mengakses ke dalam basis data dapat ditempatkan dalam
satu tempat yang sama. Hal ini akan memudahkan
programmer dalam melakukan maintenance aplikasi untuk
kedepannya, sebab kerapian akan membuat programmer
mudah untuk melakukan modifikasi, dan lebih mudah bagi
100
programmer baru (yang tidak membuat SP itu sendiri)
untuk dapat memahami alur program.
2.2.3.10.
Profiler
Pendeteksian masalah ketika kegagalan pengiriman
data terjadi merupakan tantangan tersendiri yang harus diatasi
untuk membuat sistem basis data aplikasi yang reliable. Itulah
sebabnya hadir profiler dalam SSB sebagai pemantau dimana
letak error yang menyebabkan kegagalan pengiriman message.
Profiler
memiliki
bagian-bagian
dari
event
yang
diperuntukkan untuk SSB. Perlu diketahui bahwa SSB
conversation selalu dilakukan antara 2 titik. Ini artinya kita
harus memantau kedua titik tersebut dengan menggunakan
profiler untuk mendapatkan keseluruhan gambar tentang apa
yang terjadi, antara lain:
•
Broker:Activation ditembakkan pada saat queue mulai
mengaktifkan sebuah SP.
•
Broker:Connection melaporkan status dari transport
connection yang diatur oleh SSB.
•
Broker:Conversation melaporkan perkembangan dari
conversation.
•
Broker:Conversation Group ditembakkan pada saat
conversation group dibuat atau dihapus.
101
•
Broker:Corrupted Message ditembakkan pada saat sebuah
corrupt message diterima.
•
Broker:Forwarded Message D ropped ditembakkan pada
saat
sebuah
message,
yang
dimaksudkan
untuk
dijalankan(forwarding), dihapus.
•
Broker:Forwarded Message Sent ditembakkan pada saat
sebuah message sukses dijalankan (forwarding).
•
Broker:Message Classify ditembakkan pada saat routing
untuk sebuah pesan telah ditentukan.
•
Broker:Message Undeliverable ditembakkan pada saat
message, yang seharusnya dikirim ke sebuah service, tidak
dapat disimpan.
•
Broker:Queue Disabled ditembakkan pada saat poison
message ditemukan. Ini artinya ada 5 transaksi roll back
berurutan dalam SSB queue. Pada halaman ini berisi basis
data ID dan queue ID dari queue yang berisi poison
message.
•
Broker:Remote Message Acknowledgement ditembakkan
pada saat sebuah message balasan dikirim atau diterima.
•
Broker:Transmission ditembakkan pada saat transport
error terjadi di dalam transport layer. Error number dan
state value menunjukkan sumber error.
102
•
Security Audit:Audit Broker Login melaporkan audit
message yang berhubungan dengan Service Broker
transport security.
•
Security Audit:Audit Broker Conversation melaporkan
audit message yang berhubungan dengan Service Broker
dialog security.
Beberapa dari event ini memiliki sebuah kolom
EventSubClass yang menyediakan informasi mengenai event
tersebut, yang disebut
Catalog
Views and
Dynamic
Management Views. Dengan mengamatinya, maka dapat
diketahui pada bagian mana error pengiriman message ini
terjadi, sehingga dapat dicarikan solusinya.
2.3. Tinjauan Pustaka
Pengarang
Judul
dan
Tabel Basis
Fungsionalitas
Skripsi
Review
Data
Tahun
Pembuatan
Data Klien yang
PT Asuransi
Ritaningsih,
memiliki polis pada PT
Jiwasraya
Basis Data
Fitriadi
Asuransi Jiwasraya
menggunakan
untuk
Pradana,
berkaitan dengan tabel
aplikasi CRM
Analisa dan
Tresna
Perancangan
Klien
103
M endukung
Reviana
Kantor, Agama,
untuk
Sistem
2007
Identitas, Agen,
membantu para
Beneficiary.
klien dan calon
CRM
Berbasis
Agama
Data agama yang dianut klien mereka
Web pada
oleh klien, berkaitan
untuk
PT Asuransi
dengan tabel Klien.
mendapatkan
informasi yang
Jiwasraya
Identitas
Valuta
Polis
Data Identitas yang
akurat melalui
dimiliki oleh klien,
web.
berkaitan dengan tabel
Web yang saat
Klien.
ini sudah
Data valuta yang
tersedia
digunakan untuk
memiliki
membayar polis,
fungsionalitas
berkaitan dengan tabel
sebagai
Polis.
penampil
Data detail transaksi
informasi saja
polis yang diambil oleh
dan kurang
klien, berkaitan dengan
memiliki
tabel Kantor,
rancangan basis
Beneficiary, Agen,
data yang pas.
Penagih, Valuta,
M isalnya saja
104
Beneficiary
CaraBayar,
untuk setiap
HistoriPremi,
polis baru akan
ProdukBenefitPremi.
memiliki satu
Data orang yang akan
account baru
menerima hasil polis
untuk
(tertanggung), berkaitan pengaksesan
CaraBayar
Penagih
Agen
dengan tabel Polis,
web, padahal
Klien
satu user dapat
Data cara pembayaran
memiliki lebih
yang akan dilakukan
dari satu polis.
dalam membayar polis
Hal ini
secara berkala,
membuat klien
berkaitan dengan tabel
sulit untuk
Polis.
mengingat
Data Karyawan yang
account yang
bertanggungjawab
lebih dari satu
sebagai Penagih polis
dan akhirnya
tertentu, berkaitan
tidak efektif.
dengan tabel Polis,
Transaksi lain
Kantor.
yang dapat
Data karyawan yang
dilakukan pada
bertanggungjawab
aplikasi web ini
105
Kantor
sebagai agen untuk
seperti
menawarkan polis
pengajuan klaim
tertentu, berkaitan
dan sebagainya
dengan tabel Polis,
masih belum
Kantor
tersedia
Data Kantor-kantor PT
Asuransi Jiwasraya
yang telah berdiri
sampai saat ini,
berkaitan dengan tabel
Agen, Penagih, Klien,
Polis
Dengan
permasalahan
tersebut, maka
dirancanglah
basis data yang
baru yang tidak
lagi memiliki
redundancy
Histori Premi
Data histori
pembayaran premi yang
telah dilakukan klien,
berkaitan dengan tabel
Polis
serta dapat
memenuhi
kebutuhan fitur
yang baru.
Fungsi web
Polis Benefit
Berisi data produk,
awal yang
Premi
polis, benefit dan klaim
hanya sebagai
yang dilakukan oleh
penampil
klien, berkaitan dengan
informasi klien
106
Produk Benefit
tabel Polis.
dikembangkan
Data gabungan antara
lebih lanjut agar
tabel Produk dan
dapat
Benefit, untuk
melakukan
menghilangkan relasi
klaim lewat
many-to-many antara
web,
Produk dengan
menampilkan
PolisBenefitPremi dan
tidak hanya
Produk dengan
detail polis
PolisBenefitPremi,
klien, namun
berisi data Produk dan
juga produk-
Benefit pada polis.
produk PT
Tabel ini berkaitan
Asuransi
dengan tabel Polis,
Jiwasraya.
PolisBenefitPremi,
Produk, Benefit.
Produk
Data jenis produk polis
yang digunakan,
berkaitan dengan tabel
ProdukBenefit.
Benefit
Data jenis benefit yang
terdapat pada polis,
107
berkaitan dengan tabel
Produk Benefit.
Analisis dan
Naga Basuki,
Perancangan
Alaysius,
Sistem
Pengiriman
M urtianingsih
PT Sukandi
Pengiriman yang
Djaya
dilakukan, berkaitan
merupakan
dengan tabel Pelanggan, perusahaan
Basis Data
Terdistribusi
Berisi data transaksi
2007
Persediaan
OderPenjualan,
importir
Pegawai, Barang.
makanan
Barang pada
minuman yang
PT Sukanda
awalnya
Djaya
menggunakan
Order Penjualan
Berisi data detail
sistem manual
penjualan barang,
dalam
berkaitan dengan tabel
pencatatan
Pelanggan, Pengiriman,
transaksi utama
Pegawai, Barang,
seperti
Penagihan.
penjualan,
pembelian,
Pelanggan
Berisi data pelanggan
stock barang.
yang pernah ataupun
masih bertransaksi
dengan perusahaan,
berkaitan dengan tabel
Kemudian
karena tuntutan
akan kebutuhan
108
Pegawai
OrderPenjualan,
informasi yang
PembayaranPelanggan,
akurat dan real
Pengiriman, Barang.
time, maka
Berisi data karyawan
sistem tersebut
yang bekerja pada
diubah menjadi
perusahaan, berkaitan
sistem
dengan tabel Penagihan, terkomputerisasi
Pengiriman,
dengan
PembayaranPelanggan,
pendekatan
OrderPenjualan,
basis data
PembayaranPemasokan, terdistribusi.
FakturM asuk,
FakturKeluar,
OrderPembelian
Penagihan
Berisi detail penagihan
dari pelanggan,
berkaitan dengan tabel
OrderPenjualan,
Pegawai,
PembayaranPelanggan
Faktur Keluar
Berisi detail transaksi
yang berhubungan
Sistem yang
saat ini ada
tidak
memungkinkan
untuk
diperolehnya
basis data yang
dapat membantu
proses
pengambilan
keputusan.
109
Barang
dengan penjualan,
Untuk
berkaitan dengan tabel
mengecek stock
Pegawai,
barang yang
OrderPenjualan,
tersedia saja
Barang.
masih
Berisi data barang yang
mengalami
dijual, berkaitan degnan kesulitan,
tabel Pengiriman,
apakah jumlah
OrderPembelian,
barang fisik
OrderPenjualan,
yang tersedia
Pelanggan,
sesuai dengan
FakturKeluar,
jumlah barang
FakturM asuk,
pada faktur.
PenerimaanBarang.
Proses
Penerimaan
Berisi detail barang
pencatatan dan
Barang
yang masuk, berkaitan
penyimpanan
dengan tabel Pegawai,
data file pun
Barang,
tersebar tanpa
OrderPembelian.
arah yang tentu
Order
Berisi detail transaksi
sehingga
Pembelian
pembelian barang,
kesulitan
berkaitan dengan tabel
pengaksesan
110
Pegawai, FakturM asuk,
pun terjadi.
PenerimaanBarang,
Terlebih lagi
PembayaranPemasok,
perusahaan ini
Pemasok.
sudah memiliki
Pembayaran
Berisi detail
beberapa
Pelanggan
pembayaran yang telah
cabang yang
dan harus dilakukan
tersebar di
pelanggan, berkaitan
beberapa
dengan tabel Pelanggan
propinsi, tentu
dan Pegawai
akan lebih sulit
Berisi detail transaksi
lagi untuk
yang berhubungan
menelusuri arus
dengan pembelian,
barang keluar –
berkaitan dengan tabel
masuk.
Faktur M asuk
Pegawai,
OrderPembelian,
Barang.
Pemasok
Berisi data pemasok
barang pada perusahaan
ini, berkaitan dengan
tabel OrderPembelian.
Pembayaran
Berisi data pembayaran
Dengan
permasalahan
tersebut, maka
dirancanglah
basis data baru
yang dapat
memenuhi
kebutuhan
111
Pemasok
yang telah dan harus
daripada
dibayar kepada
perusahaan ini.
pemasok, berkaitan
Segala macam
dengan tabel Pegawai,
proses
OrderPembelian.
operasional
transaksi dapat
langsung dientry pada
komputer untuk
dapat
mengurangi
human error.
Tabel 2.1
Tinjauan Pustaka