bab 2 landasan teori 2.1. teori umum - library.binus.ac.id filesecara tipikal menggambarkan...
TRANSCRIPT
9
BAB 2
LANDASAN 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 / DBMS) 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.
10
2.1.1. Pengertian Basis Data
Menurut 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 DBMS / Sistem Manajemen Basis Data menjadi
program yang mengatur dan mengontrol akses ke basis data tersebut serta
memelihara informasi dan menjadikan informasi tersebut tersedia
berdasarkan permintaan.
Menurut 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.
Menurut 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
Menurut 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 DBMS 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
Menurut Connolly (2005, pp18-21), terdapat lima komponen
utama dalam lingkungan DBMS, 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 : DBMS, 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 DBMS.
Pengguna sistem tersebut dan karyawan yang mengelola basis data
13
memerlukan dokumentasi prosedur dan bagaimana sistem itu
dijalankan. Prosedur tersebut meliputi :
• Masuk ke dalam DBMS
• Menggunakan fasilitas DBMS atau aplikasi program
• Memulai dan menghentikan DBMS
• Membuat backup dan recovery basis data
• Menangani kesalahan perangkat keras dan perangkat lunak
5. Orang adalah komponen yang terkait dengan sistem. Orang dibagi
menjadi 4, yaitu:
• Data and Database Administrator
Data Administrator bertanggung jawab terhadap
manajemen dari sumber data (data resource) termasuk
perencanaan (planning), pengembangan (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
Menurut Connolly (2005, pp26-30), sistem manajemen basis data
memiliki keuntungan sekaligus kerugian.
Keuntungan DBMS :
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)
DBMS menyediakan banyak fungsi standar yang dapat memudahkan
programmer. DBMS juga menyediakan sebuah lingkungan fourth-
generation 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)
DBMS 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)
DBMS 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)
DBMS menyediakan fasilitas yang dapat mengurangi proses yang
akan mengalami kegagalan.
Kerugian DBMS :
1. Kompleksitas (Complexity)
Ketentuan-ketentuan dari fungsionalitas yang kita harapkan dari
sebuah DBMS yang baik membuat DBMS menjadi sebuah bagian
dari software yang sangat rumit.
2. Ukuran (Size)
Kompleksitas dan luasnya fungsionalitas yang dimiliki DBMS
membuat DBMS 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 DBMS (Cost of DBMSs)
Biaya DBMS berubah-ubah secara signifikan, tergantung pada
lingkungan dan fungsionalitas yang disediakan.
4. Biaya perangkat keras tambahan (Additional hardware costs)
Kebutuhan akan tempat penyimpanan untuk DBMS 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 DBMS.
5. Biaya konversi (Cost of conversion)
Dalam beberapa situasi, biaya DBMS dan hardware tambahan tidak
bisa dibandingkan dengan biaya konversi aplikasi yang sudah ada
untuk dijalankan pada DBMS 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 DBMS ‘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 DBMS, Kegagalan beberapa komponen dapat
menghentikan operasi.
2.1.5. Database Languages
Menurut 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
Meta data adalah data yang menggambarkan objek dalam
basis data dan membuatnya lebih mudah untuk diakses dan
dimanipulasi. Meta data berisi definisi dari record, data item, objek
lain yang menjadi minat ke para pemakai atau diperlukan oleh
DBMS. DBMS 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 :
• Menambahkan data baru ke dalam basis data
• Memodifikasi data yang tersimpan dalam basis data
• Memperoleh kembali data yang terdapat dalam basis data
• Menghapus data dari basis data
DML 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
Menurut Codd (1982), terdapat 8 fungsi yang seharusnya
disediakan oleh DBMS. Dan Connolly (2005, pp48-52) menambahkan 2
fungsi yang diharapkan ada. Fungsi-fungsi tersebut adalah
1. Tempat penyimpanan, penerimaan, dan pembaharuan data
Sebuah DBMS harus melengkapi user dengan kemampuan untuk
menyimpan, mendapatkan kembali, dan memperbaharui data di dalam
database.
2. Sebuah katalog yang user-accessible
Sebuah DBMS harus dilengkapi dengan sebuah catalog yang di
dalamnya berisi deskripsi dari item data yang disimpan dan dapat
diakses oleh user.
3. Mendukung transaksi
Sebuah DBMS 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. Mendukung kendali concurrency
Sebuah DBMS 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 DBMS harus dilengkapi dengan sebuah mekanisme untuk
mengembalikan (recovering) basis data pada saat basis data
mengalami kerusakan.
6. Authorization service
Sebuah DBMS harus dilengkapi dengan sebuah mekanisme yang
menjamin bahwa hanya user yang memiliki hak akses yang dapat
mengakses basis data.
7. Mendukung komunikasi antar data
Sebuah DBMS harus dapat terintegrasi dengan software komunikasi.
8. Integrity service
Sebuah DBMS harus dilengkapi dengan arti (means) untuk
memastikan data di dalam basis data dan perubahan pada data
mengikuti aturan tertentu.
9. Data independent service
Sebuah DBMS harus termasuk fasilitas untuk mendukung program
yang independen dari struktur sebenarnya dari basis data.
10. Utility services
Sebuah DBMS 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
Menurut 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
Menurut 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.
Menurut 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.
Menurut Connolly (2005, 81), null menampilkan sebuah nilai
untuk sebuah atribut yang tidak diketahui atau tidak dapat
diterapkan untuk tuple ini.
Menurut 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.
Menurut 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 basis data merupakan perencanaan
bagaimana tahapan-tahapan dalam 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.
Metodologi 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. Aktivitas
penting lainnya ialah menentukan 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.
Model-model yang menampilkan user view tunggal
disebut local data model, dan tersusun atas diagram-
31
diagram dan dokumentasi yang secara formal
menggambarkan kebutuhan dari user view khusus
terhadap basis data. Kemudian local data model
digabungkan untuk menghasilkan global data model, yang
menampilkan seluruh user view untuk basis data.
• Kombinasi keduanya (Combination of both approaches)
2.1.8.4. Perancangan Basis Data (Database Design)
Perancangan basis data merupakan suatu proses
pembuatan sebuah rancangan basis data yang akan
mendukung tujuan dan operasi suatu perusahaan. Tujuan
utamanya adalah :
• Menampilkan data dan relationship antar data yang
dibutuhkan oleh seluruh area aplikasi utama dan user
group.
• Menyediakan model data yang mendukung segala
transaksi yang diperlukan pada data.
• Menspesifikasikan 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
Menggunakan pendekatan bottom-up dan top-down untuk
bagian yang berbeda sebelum pada akhirnya digabungkan.
Menurut Connolly (2005, pp293-295), terdapat 3 fase
dalam perancangan basis data, yaitu :
• Perancangan Basis Data Konseptual (Conceptual
Database Design)
33
Suatu proses pembentukan model dari informasi yang
digunakan dalam perusahaan, independen dari keseluruhan
aspek fisik. Model data dibangun dengan menggunakan
informasi dalam spesifikasi kebutuhan pemakai. Model
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
DBMS tertentu dan aspek fisik lainnya. Model 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
DBMS tertentu.
34
2.1.8.5. Pemilihan DBMS (DBMS Selection)
Pemilihan DBMS 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 DBMS :
• Mendefinisikan terminologi studi referensi.
• Mendaftarkan dua atau tiga produk.
• Evaluasi produk.
• Rekomendasi pilihan dan laporan produk.
2.1.8.6. 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.
Menggunakan 3GL dan 4GL untuk membuat program
aplikasi. Transaksi basis data juga turut disertakan dengan
menggunakan DML, 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.
DBMS 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
Menurut 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. Menurut 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 Jenis Entiti
2.1.10.2. Jenis Relasi (Relationship Types)
Menurut Connolly (2005, p347), Relationship type
adalah kumpulan hubungan yang mempunyai arti antara entity
type. Sementara Relationship occurrence merupakan
hubungan yang dikenali secara unik, yang meliputi
keberadaan dari setiap entity type yang berpartisipasi.
Menurut Connolly (2005, pp347-348), Degree of
Relationship Type adalah jumlah entity type yang
berpartisipasi dalam sebuah relationship. Degree of
Relationship Type terdiri dari :
• Binary Relationship : Hubungan antara dua entity type.
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
Menurut 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)
Menurut Connolly (2005, pp350-354), Atribut adalah
properti dari sebuah entity atau relationship type. Contohnya :
sebuah entity karyawan digambarkan oleh kdKary, nmKary,
almtKary dan jabatan.
Macam-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. Misalkan atribut alamat dapat terdiri dari
jalan, kota dan kode pos.
• Single-value Attribute
Atribut yang mempunyai nilai tunggal untuk setiap
kejadian. Misalnya entity pemesanan memiliki satu nilai
untuk attribut noPesan pada setiap kejadian.
• Multi-value Attribute
Atribut yang mempunyai beberapa nilai untuk setiap
kejadian. Misalnya 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.
Maka, 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.
Menurut 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
Menurut 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
Menurut 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
Menurut 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
Menurut 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 (Maier, 1983).
Menurut Connolly (2005, pp393-399), karakteristik
dari sebuah functional dependency dibagi 3 :
1. Functional Dependency
49
Menjelaskan 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
Menunjukkan 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)
Menurut Connolly (2005, p403), UNF adalah sebuah tabel
yang terdiri dari satu atau lebih repeating group.
2. First Normal Form (1NF)
50
Menurut 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)
Menurut 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)
Menurut 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)
Menurut Connolly (2005, 419), BCNF adalah sebuah relasi di dalam
BCNF, jika dan hanya jika setiap determinant adalah candidate key.
2. Fourth Normal Form (4NF)
Menurut 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
Menurut 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. Model data
dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan
pemakai. Model data konseptual merupakan sumber informasi untuk
tahap perancangan logikal.
Langkah-langkah untuk perancangan basis data konseptual :
1. Membangun model data konseptual
Bertujuan untuk membangun model data konseptual dari kebutuhan
data suatu perusahaan.
a. Mengenali tipe entity
Bertujuan untuk mengenali tipe entity yang dibutuhkan.
b. Mengenali tipe relationship
Bertujuan untuk mengenali relationship penting yang ada di
antara tipe entity
c. Mengenali dan menghubungkan atribut dengan entity atau tipe
relationship
Bertujuan untuk menggabungkan atribut-atribut dengan entity
atau tipe relationship yang sesuai.
d. Menentukan attribute domain
52
Bertujuan untuk menentukan domain untuk atribut di dalam
model data konseptual lokal.
e. Menentukan 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. Mempertimbangkan penggunaan enhanced modeling concept
(optional)
Bertujuan untuk mempertimbangkan penggunaan enhanced
modeling concept, seperti specialization/generalization,
aggregation dan composition.
g. Memeriksa model untuk redudansi
Bertujuan untuk memeriksa kehadiran dari redundancy di dalam
model.
h. Memvalidasi model konseptual terhadap transaksi user
Bertujuan untuk memastikan bahwa model konseptual
mendukung transaksi yang dibutuhkan.
i. Melihat 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 DBMS tertentu dan aspek fisik lainnya.
Model data konseptual yang telah dibuat sebelumnya, diperbaiki dan
dipetakan kedalam model data logikal.
Langkah-langkah untuk perancangan basis data logikal :
a Membangun 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. Mendapatkan relasi untuk data model logikal
Bertujuan untuk membuat relasi untuk model data logikal yang
menampilkan entity, relationship, dan atribut yang sudah
dikenali.
c. Memvalidasi relasi menggunakan normalisasi
Bertujuan untuk memvalidasi relasi pada model data logikal
menggunakan normalisasi.
d. Memvalidasi relasi terhadap transaksi user
Bertujuan untuk memastikan relasi pada model data logikal
mendukung transaksi yang dibutuhkan.
e. Memeriksa integrity constraint
54
Bertujuan untuk memeriksa integrity constraint yang ditampilkan
pada model data logikal.
f. Melihat 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. Menggabungkan 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. Memeriksa 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
DBMS tertentu.
Langkah-langkah untuk perancangan basis data fisikal :
a. Mewujudkan model data logical untuk target DBMS
Bertujuan untuk menghasilkan skema relasional basis data dari
model data logikal yang dapat diterapkan pada target DBMS.
b. Merancang relasi dasar
Bertujuan untuk memutuskan bagaimana menampilkan relasi
dasar yang dikenali di model data logikal di dalam target DBMS.
c. Merancang tampilan dari derived data
Bertujuan untuk memutuskan bagaimana menampilkan setiap data
yang didapat di model data logikal di dalam target DBMS.
d. Merancang general constraint
Bertujuan untuk merancang general constraint untuk target
DBMS.
e. Merancang 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. Menganalisa transaksi
56
Bertujuan untuk memahami fungsionalitas dari transaksi yang
akan dijalankan pada basis data dan untuk menganalisa transaksi
penting.
g. Memilih file organisasi
Bertujuan untuk menentukan file organisasi yang efisien untuk
setiap relasi dasar.
h. Memilih indeks
Bertujuan untuk menentukan apakah dengan menambahkan
indeks akan meningkatkan kinerja dari sistem.
i. Memperkirakan kebutuhan ruang disk
Bertujuan untuk memperkirakan jumlah dari disk yang dibutuhkan
untuk basis data.
j. Merancang user views
Bertujuan untuk merancang user view yang dikenali selama
requirement collection dan menganalisa database system
development lifecycle.
k. Merancang mekanisme keamanan
Bertujuan untuk merancang mekanisme keamanan untuk basis
data seperti yang ditetapkan user selama requirement dan
collection dari database system development lifecycle.
l. Mempertimbangkan pengenalan kontrol redudansi
m. Memantau 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
Memberikan fungsi shortcut agar pemakai yang sering menggunakan
dapat menggunakan aplikasi lebih cepat dan mudah.
3. Umpan balik yang informative
Memberikan 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
Menyediakan 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 primitif secara
fungsional dan disebut sebagai proses primitif.
61
2.2. Teori Khusus
2.2.1. Service Oriented Database Architecture (SODA)
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
Merupakan 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
Merupakan basis data yang digunakan.
2.2.1.2. Layer pada SODA
Gambar 2.13 Layer SODA
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 XML
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
• Mengunakan 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 XML, 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 DBMS (DataBase Management
System) adalah software system yang mengatur
pendistribusian basis data dan membuat sistem terdistribusi
yang jelas kepada user. DDBMS ini merupakan satu kesatuan
69
basis data logic yang tersebar dalam fragment pada masing –
masing komputer yang terpisah, namun dikendalikan oleh
suatu DBMS 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 DDBMS :
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 DBMS
Setiap DBMS pasti memiliki minimal satu aplikasi
global
Distributed Processing merupakan centralized
database yang bisa diakses melalui jaringan komputer.
Memiliki sebuah pusat database dan semua site mengaksesnya
melalui jaringan. Sedangkan Parallel DBMS (Tambahan )
merupakan DBMS 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, DDBMS
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 DBMS, ketika satu komputer pusat
terjadi gangguan pada DBMSnya, maka seluruh bagian
dari DBMS akan terhenti. Tetapi pada distributed DBMS
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. Misalnya 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 DDBMS, 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
DDBMS 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
DDBMS, juga tidak ada metodologi khusus yang
membantu user mengubah centralized DBMS ke
distributed DBMS.
Lack of experience
Teknologi ini masih terbatas dan lebih jarang digunakan
dibandingkan dengan centralized DBMS.
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
DDBMS yang baik memiliki fungsi berikut ini :
Meningkatkan communication services untuk
menyediakan akses data ke lokal dan memungkinkan
untuk proses transfer query dan data melalui jaringan.
Memperluas sistem katalog untuk menyimpan detail dari
distribusi data.
Dapat melakukan query secara terdistribusi, termasuk
query optimization dan remote data access.
Memperluas security control untuk membuat autorisasi
terhadap akses basis data.
Memperluas concurrency control untuk menjamin
konsistensi data terdistribusi
Meningkatkan 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 DDBMS:
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
Merupakan deskripsi bagaimana data – data tersebut
dibagi – bagi secara logical.
Local schema
Merupakan perancangan skema di masing - masing bagian
basis data.
2.2.2.5. Komponen Arsitektur DDBMS
Terdiri dari 4 macam :
Local DBMS Component
DBMS yang dibutuhkan untuk mengatur data di lokal
Data communications Component
DC component memungkinkan semua site saling
berhubungan.
Global System Catalog
75
Menyimpan informasi dari keseluruhan proses yang
terjadi, komunikasi yang terjadi, dan data apa saja yang
melewati jaringan.
Distributed DBMS Component
Mengontrol 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. Misalnya 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
Menempatkan 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. Misalnya 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 (SSB)
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
Merupakan kumpulan dialog conversation yang saling
berhubungan. SSB menyediakan lock pada conversation
80
group untuk pengadaan fungsionalitas Exactly-Once-In-
Order (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.
Misalnya 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. Misalnya 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:
• Message Types
83
Menjelaskan 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. Message 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
Membuat 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 secara otomatis dan menghilangkan
permasalahan administratif seperti memutuskan berapa
banyak entitas messaging yang dibutuhkan. SSB terlibat
langsung dengan fitur manajemen basis data yakni SP, XML,
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 query-
query 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
• Messages
• 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 XML 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 Service Broker Database
Gambar 2.20 Service Broker
2.2.3.7. SQL Service Broker Security
SSB memiliki kebutuhan keamanan seperti halnya
aplikasi database lain. Model SSB mengikuti model
komunikasi dimana SSB 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 (SP)
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 Procedure
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 Dropped 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
Judul
Skripsi
Pengarang
dan
Tahun
Pembuatan
Tabel Basis
Data Fungsionalitas Review
Analisa dan
Perancangan
Basis Data
untuk
Tresna
Ritaningsih,
Fitriadi
Pradana,
Klien Data Klien yang
memiliki polis pada PT
Asuransi Jiwasraya
berkaitan dengan tabel
PT Asuransi
Jiwasraya
menggunakan
aplikasi CRM
103
Kantor, Agama,
Identitas, Agen,
Beneficiary.
Mendukung
Sistem
CRM
Berbasis
Web pada
PT Asuransi
Jiwasraya
Reviana
2007
Agama Data agama yang dianut
oleh klien, berkaitan
dengan tabel Klien.
Identitas Data Identitas yang
dimiliki oleh klien,
berkaitan dengan tabel
Klien.
Valuta Data valuta yang
digunakan untuk
membayar polis,
berkaitan dengan tabel
Polis.
Polis Data detail transaksi
polis yang diambil oleh
klien, berkaitan dengan
tabel Kantor,
Beneficiary, Agen,
Penagih, Valuta,
untuk
membantu para
klien dan calon
klien mereka
untuk
mendapatkan
informasi yang
akurat melalui
web.
Web yang saat
ini sudah
tersedia
memiliki
fungsionalitas
sebagai
penampil
informasi saja
dan kurang
memiliki
rancangan basis
data yang pas.
Misalnya saja
104
CaraBayar,
HistoriPremi,
ProdukBenefitPremi.
Beneficiary Data orang yang akan
menerima hasil polis
(tertanggung), berkaitan
dengan tabel Polis,
Klien
CaraBayar Data cara pembayaran
yang akan dilakukan
dalam membayar polis
secara berkala,
berkaitan dengan tabel
Polis.
Penagih Data Karyawan yang
bertanggungjawab
sebagai Penagih polis
tertentu, berkaitan
dengan tabel Polis,
Kantor.
Agen Data karyawan yang
bertanggungjawab
untuk setiap
polis baru akan
memiliki satu
account baru
untuk
pengaksesan
web, padahal
satu user dapat
memiliki lebih
dari satu polis.
Hal ini
membuat klien
sulit untuk
mengingat
account yang
lebih dari satu
dan akhirnya
tidak efektif.
Transaksi lain
yang dapat
dilakukan pada
aplikasi web ini
105
sebagai agen untuk
menawarkan polis
tertentu, berkaitan
dengan tabel Polis,
Kantor
Kantor Data Kantor-kantor PT
Asuransi Jiwasraya
yang telah berdiri
sampai saat ini,
berkaitan dengan tabel
Agen, Penagih, Klien,
Polis
Histori Premi Data histori
pembayaran premi yang
telah dilakukan klien,
berkaitan dengan tabel
Polis
Polis Benefit
Premi
Berisi data produk,
polis, benefit dan klaim
yang dilakukan oleh
klien, berkaitan dengan
seperti
pengajuan klaim
dan sebagainya
masih belum
tersedia
Dengan
permasalahan
tersebut, maka
dirancanglah
basis data yang
baru yang tidak
lagi memiliki
redundancy
serta dapat
memenuhi
kebutuhan fitur
yang baru.
Fungsi web
awal yang
hanya sebagai
penampil
informasi klien
106
tabel Polis.
Produk Benefit Data gabungan antara
tabel Produk dan
Benefit, untuk
menghilangkan relasi
many-to-many antara
Produk dengan
PolisBenefitPremi dan
Produk dengan
PolisBenefitPremi,
berisi data Produk dan
Benefit pada polis.
Tabel ini berkaitan
dengan tabel Polis,
PolisBenefitPremi,
Produk, Benefit.
Produk Data jenis produk polis
yang digunakan,
berkaitan dengan tabel
ProdukBenefit.
Benefit Data jenis benefit yang
terdapat pada polis,
dikembangkan
lebih lanjut agar
dapat
melakukan
klaim lewat
web,
menampilkan
tidak hanya
detail polis
klien, namun
juga produk-
produk PT
Asuransi
Jiwasraya.
107
berkaitan dengan tabel
Produk Benefit.
Pengiriman
Berisi data transaksi
Pengiriman yang
dilakukan, berkaitan
dengan tabel Pelanggan,
OderPenjualan,
Pegawai, Barang.
Order Penjualan Berisi data detail
penjualan barang,
berkaitan dengan tabel
Pelanggan, Pengiriman,
Pegawai, Barang,
Penagihan.
Analisis dan
Perancangan
Sistem
Basis Data
Terdistribusi
Persediaan
Barang pada
PT Sukanda
Djaya
Naga Basuki,
Alaysius,
Murtianingsih
2007
Pelanggan Berisi data pelanggan
yang pernah ataupun
masih bertransaksi
dengan perusahaan,
berkaitan dengan tabel
PT Sukandi
Djaya
merupakan
perusahaan
importir
makanan
minuman yang
awalnya
menggunakan
sistem manual
dalam
pencatatan
transaksi utama
seperti
penjualan,
pembelian,
stock barang.
Kemudian
karena tuntutan
akan kebutuhan
108
OrderPenjualan,
PembayaranPelanggan,
Pengiriman, Barang.
Pegawai Berisi data karyawan
yang bekerja pada
perusahaan, berkaitan
dengan tabel Penagihan,
Pengiriman,
PembayaranPelanggan,
OrderPenjualan,
PembayaranPemasokan,
FakturMasuk,
FakturKeluar,
OrderPembelian
Penagihan Berisi detail penagihan
dari pelanggan,
berkaitan dengan tabel
OrderPenjualan,
Pegawai,
PembayaranPelanggan
Faktur Keluar Berisi detail transaksi
yang berhubungan
informasi yang
akurat dan real
time, maka
sistem tersebut
diubah menjadi
sistem
terkomputerisasi
dengan
pendekatan
basis data
terdistribusi.
Sistem yang
saat ini ada
tidak
memungkinkan
untuk
diperolehnya
basis data yang
dapat membantu
proses
pengambilan
keputusan.
109
dengan penjualan,
berkaitan dengan tabel
Pegawai,
OrderPenjualan,
Barang.
Barang Berisi data barang yang
dijual, berkaitan degnan
tabel Pengiriman,
OrderPembelian,
OrderPenjualan,
Pelanggan,
FakturKeluar,
FakturMasuk,
PenerimaanBarang.
Penerimaan
Barang
Berisi detail barang
yang masuk, berkaitan
dengan tabel Pegawai,
Barang,
OrderPembelian.
Order
Pembelian
Berisi detail transaksi
pembelian barang,
berkaitan dengan tabel
Untuk
mengecek stock
barang yang
tersedia saja
masih
mengalami
kesulitan,
apakah jumlah
barang fisik
yang tersedia
sesuai dengan
jumlah barang
pada faktur.
Proses
pencatatan dan
penyimpanan
data file pun
tersebar tanpa
arah yang tentu
sehingga
kesulitan
pengaksesan
110
Pegawai, FakturMasuk,
PenerimaanBarang,
PembayaranPemasok,
Pemasok.
Pembayaran
Pelanggan
Berisi detail
pembayaran yang telah
dan harus dilakukan
pelanggan, berkaitan
dengan tabel Pelanggan
dan Pegawai
Faktur Masuk Berisi detail transaksi
yang berhubungan
dengan pembelian,
berkaitan dengan tabel
Pegawai,
OrderPembelian,
Barang.
Pemasok Berisi data pemasok
barang pada perusahaan
ini, berkaitan dengan
tabel OrderPembelian.
Pembayaran Berisi data pembayaran
pun terjadi.
Terlebih lagi
perusahaan ini
sudah memiliki
beberapa
cabang yang
tersebar di
beberapa
propinsi, tentu
akan lebih sulit
lagi untuk
menelusuri arus
barang keluar –
masuk.
Dengan
permasalahan
tersebut, maka
dirancanglah
basis data baru
yang dapat
memenuhi
kebutuhan
111
Pemasok yang telah dan harus
dibayar kepada
pemasok, berkaitan
dengan tabel Pegawai,
OrderPembelian.
daripada
perusahaan ini.
Segala macam
proses
operasional
transaksi dapat
langsung di-
entry pada
komputer untuk
dapat
mengurangi
human error.
Tabel 2.1 Tinjauan Pustaka