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