2013100873SIBab2001

BAB 2

LANDASAN TEORI

2.1

Teori – Teori Umum

Penyusunan skripsi ini memiliki beberapa teori-teori umum yang digunakan

sebagai landasan.Berikut dibawah ini adalah pemaparan terhadap teori-teori tersebut.

2.1.1

Basis Data

Menurut Conolly (2010, p65) basis data merupakan suatu koleksi

bersama data-data yang saling terkait secara logis, dan juga merupakan

pendeskripsian dari data-data tersebut, yang dirancang untuk menyajikan

informasi yang dibutuhkan oleh sebuah organisasi.

Cahyono (2009, 83) mendefinisikan “basis data merupakan salah satu

komponen sistem informasi mempunyai posisi yang menentukan dalam

menunjang keberhasilan suatu sistem informasi.”

Sedangkan menurut O’Brien dan Marakas (2008, p163), Basis Data

merupakan koleksi terpadu dari elemen data yang terkait secara logis.

Dalam basisdata, terdapat tiga istilah penting, yakni entitas, atribut,

dan relationship. (Conolly, 2010, p65).

Maka dengan demikian dapat disimpulkan bahwa basis data

merupakan sekumpulan banyak data yang ada di dalam suatu organisasi

dimana data tersebut saling terkait atau terhubung secara logis dan digunakan

untuk memenuhi kebutuhan informasi organisasi.

Menurut

Conolly

(2010,p54)

Hirarki data

dalam

database

mulai

dari

yang

terbesar ke yang terkecil yaitu :

1. Database

Suatu database menggambarkan

data

yang

saling

berhubungan

antara

satu

dengan yang lainnya.

2. File

Suatu file menggambarkan

suatu

kesatuan

data

yang

sejenis,

dimana

kumpulan dari file membentuk suatu database.

3. Record

Suatu record menggambarkan suatu unit data

individu yang

tertentu dimana

kumpulan dari record membentuk suatu file.

4. Field

Suatu field menggambarkan,suatu attribute dari record,dimana,kumpulan

field membentuk suatu record.

5. Byte

Attribute dari field berupa huruf yang membentuk nilai dari sebuah field.

6. Bit

Merupakan bagian terkecil dari data secara keseluruhan yaitu berupa karakter

ASCII

(American

Standar

Code

Form

Information

Intercharge).

(nol)

adalah satu yang merupakan komponen pembentuk byte.

2.1.1.1 Basis Data untuk Analisis Sistem

Field

Menurut Whitten, Bentley, Dittman (2004, p520) Field

merupakan bagian

umum pada file dan database. Field adalah implementasi pada sebuah atribut

data. Field

adalah inti

terkecil pada meaningful

yang telah disimpan pada

sebuah file

atau database. Ada empat field

yang dapat di simpan: primary

key, secondary key, foreign key dan descriptive field

Primary key adalah sebuah field

yang nilai-nilainya

mengidentifikasikan

satu dan hanya satu record pada sebuah file.

Secondary key

adalah sebuah pengidentifikasi alternative

pada sebuah

database. Nilai secondary key

mungkin mengidentifikasi sebuah record

tunggal atau subset

dari semua record. Sebuah file

tunggal pada sebuah

database

dapat memiliki hanya satu primary key, tetapi juga dapat

memiliki beberapa secondary key.

Foreign key adalah field yang menunjuk kepada record pada file lain pada

sebuah database. Foreign key

memampukan database terhubung ke

record-record dari satu tipe ke record-record tipe lain.

Descriptive field adalah semua field lainnya yang menyimpan data bisnis.

• Record

Menurut Whitten, Bentley, Dittman (2004, p521) Record adalah sebuah

kumpulan field yang di susun pada format yang telah di tentukan.

• File dan Tabel

Menurut Whitten, Bentley, Dittman (2004, p521) Pada sistem database,

sebuah file

sering di sebut tabel. File

adalah kumpulan dari semua

kejadian dari struktur record

yang di tentukan sedangkan tabel adalah

ekuivalent database relasional dari sebuah file.Beberapa tipe file dan tabel

konvesional antara lain:

1. Master file atau tabel berisi record-record yang secara relatif bersifat tetap

atau permanen.

2. Transactional file

atau tabel yang terdiri dari record-record

yang

mendeskripsikan kejadian-kejadian bisnis.

3. Documents files dan tabel berisi salinan tersimpan dari data historis untuk

memudahkan pemanggilan dan review

ulang tanpa mengeluarkan biaya

tambahan untuk menghasilkan dokumen.

4. Archival files dan tabel berisi record-record file master dan transaksi yang

telah di hapus dari penyimpanan online.

5. Table look-up files

terdiri dari data yang relatif statis yang dapat di pakai

berbagai aplikasi untuk memelihara konsistensi dan peningkatan performa.

6. Audit files

adalah record-record

pembaruan khusus untuk file-file yang

lain, khususnya file master dan transaksi.

2.1.2

Fact Finding Technique

Data merupakan suatu fakta, untuk mengumpulkan fakta tersebut, tentunya

ada beberapa teknik yang digunakan agar fakta tersebut dapat diperoleh dengan

tepat. Ada beberapa definisi Fact Finding Technique seperti yang dikemukakan oleh

Bennett, McRobb, & Farmer (2010: 42-150) yang membagi teknik tersebut menjadi

lima teknik utama dalam fact finding technique

yang digunakan oleh para analis

untuk meneliti kebutuhan, yaitu :

Background Reading

Jika seorang analis dipekerjakan dalam

organisasi yang menjadi subjek dari

pelaksanaan dalam pengumpulan fakta, maka kemungkinan bahwa mereka

akan memiliki pemahaman yang baik tentang organisasi dan tujuan usahanya.

Namun jika mereka sebagai konsultan dari luar, maka salah satu tugas

pertamanya adalah mencoba untuk memperoleh pemahaman tentang

organisasi. Background reading atau penelitian merupakan bagian dari proses

tersebut. Jenis dokumen yang cocok untuk sumber informasi tersebut adalah

Laporan perusahaan

Struktur organisasi

Kebijakan pengguna

Uraian pekerjaan

Laporan

Dokumentasi sistem yang ada

Interviewing

Wawancara mungkin merupakan teknik pencarian fakta yang paling banyak

digunakan, namum juga salah satu yang memerlukan keterampilan yang paling

sensitif.

Observation

Observasi merupakan teknik pengumpulan fakta yang dilakukan dengan

terjun langsung ke lapangan. Observasi atau pengamatan juga memungkinkan

seorang analis untuk dapat melihat apa yang orang lakukan dengan

menggunakan informasi untuk melaksanakan pekerjaan mereka.

Document Sampling

Document sampling dapat digunakan dengan dua cara yang berbeda. Pertama

analisis akan mengumpulkan salinan dokumen dan diselesaikan selama

wawancara dan sesi obeservasi. Kedua, analis dapat melakukan analisis

dokumen statistik dalam rangka untuk mengetahui tentang pola data.

Questionnaires

Kuesioner merupakan suatu instrumen penelitian yang dapat diterapkan untuk

mencari fakta dalam

proyek pengembangan sistem.Pernyataan tersebut

diperkuat oleh Connolly & Begg (2010: 341)

yang mendefinisikan Fact

finding Techiques

sebagai “proses formal yang menggunakan beberapa cara

seperti wawancara dan kuisioner untuk mengumpulkan fakta tentang sistem,

kebutuhan dan preferensi”.

Lima teknik umum yang digunakan adalah :

Examining documentation

sangat berguna ketika mencoba untuk

mendapatkan keuntungan dari beberapa wawasan seperti bagaimana

mendapatkan kemunculan suatu database.

Interviewing

Teknik interview

merupakan teknik yang paling sering digunakan dan cara

paling bisa digunakan untuk fact finding.

Observing the enterprise in operation

Merupakan satu dari banyak teknik fact-finding

teknik untuk memahami

sistem.Teknik ini memungkinkan untuk salah satu partisipan atau melihat

aktifitas performa seseorang untuk mempelajari sistem tersebut.

Research

Teknik Fact finding yang berguna untuk mencari aplikasi dan problem.

Quisioner

Teknik fact finding untuk melakukan survey dengan melalui kuesioner.

2.1.3

Activity Diagram

Dalam merancang sebuah sistem informasi diperlukan sebuah diagram UML.

Diagram UML terdapat berbagai macam salah satunya adalah activity

diagram.

Activity diagram

sering digunakan untuk analisis, activity diagram

merupakan alur

kerja atau workflow

yang menjelaskan berbagai macam aktifitas sistem dan

pengguna. Seperti yang dikemukakan oleh Satzinger, Jackson, & Burd (2009: 141-

142) activity diagram

merupakan “suatu jenis diagram

alur kerja yang

menggambarkan kegiatan pengguna atau user

serta urutan sekuensialnya”.

Pernyataan tersebut diperkuat oleh Whiten & Benntley (2007: 390-391) yang

mendeskripsikan “activity

diagram

sebagai sebuah diagram dapat digunakan untuk

grafis yang menggambarkan aliran proses bisnis, langkah-langkah dari use case, atau

logika perilaku objek”.

Gambar 2.1 Simbol Activity Diagram

(Sumber: Satzinger, Jackson, & Burd, 2009: 142)

Simbol-simbol pada aktivity diagram adalah :

Swimlane

merupakan area persegi panjang pada activity diagram

yang

merepresentasikan kegiatan yang dilakukan oleh aktor.

Starting activity (Pseudo)

Starting activity berbentuk lingkaran penuh yang menggambarkan awal dari

proses.

Transition arrow

berbentuk tanda panah yang menunjukkan perkembangan

dari suatu kegiatan yang dilakukan oleh aktor.

Activity

Activity menggambarkan kegiatan-kegiatan yang dilakukan oleh aktor.

Ending activity (Pseudo)

Ending activiy berbentuk lingkaran dengan bulatan penuh di tengah lingkaran

yang menunjukkan akhirnya sebuh proses

Synchronization bar (split)

merupakan bar hitam dengan satu aliran masuk

dan dua atau lebih arus keluar.

Synchronization bar (Join)

Synchronization bar (join) bar hitam dengan dua atau lebih aliran masuk dan

satu aliran keluar, tidak ada akhir dalam pemrosesan yang bersamaan.

Decision activity

Decision activity berbentuk berlian dengan satu aliran masuk dan dua atau

lebih arus keluar.

Another way to show decision

Merupakan sebuah proses kegiatan, dimana proses tersebut dapat

menyebabkan terjadinya kegiatan atau activity lebih dari satu.

Dari pernyataan diatas dapat disimpulkan bahwa activity diagram merupakan sebuah

diagram yang menunjukkan seluruh aktivitas yang dilakukan oleh aktor, proses awal

aktivitas yang dilakukan oleh aktor ditandai dengan starting activity

dan diakhiri

dengan ending activity.

2.1.4

Konsep Model ERD

2.1.4.1 Relationship

Relationship

merupakan sebuah kumpulan keterhubungan yang mempunyai

arti antara tipe entitas yang ada (Conolly, 2010, p374).

Gambar 2.2 Relationship Branch has Staff

(Connoly, Database Systems, p375)

2.1.4.2 Structural Constraints

Batasan utama pada relationship

disebut multiplicity, yaitu jumlah (atau

range) dari kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu

kejadian dari entitas lain yang berhubungan melalui suatu relationship. Relationship

yang paling umum adalah binary relationship. Macam-macam binary relationship

adalah sebagai berikut:

Gambar 2.3 ER Diagram of Staff and Branch Entities and general constraint

(Conolly, Database Systems, p382)

Gambar 2.4 ER Diagram of Staff and Property For Rent Entities and general

constraint

(Conolly, Database Systems, p388)

Gambar 2.5 ER Diagram of Staff and PropertyForRent Entities and general

constraint

(Conolly, Database Systems, p389)

2.1.4.3 Attributes

Menurut Conolly (2010, p379) Attributes merupakan sifat-sifat (property)

dari sebuah entitas atau tipe relationship.Attribute

domain adalah himpunan nilai

yang diperbolehkan untuk satu atau lebih atribut. Macam-macam atribut adalah

sebagai berikut:

Simple Attribute, yaitu atribut yang terdiri dari satu komponen tunggal dengan

keberadaan yang independen dan tidak dapat dibagi menjadi bagian yang lebih

kecil lagi. Dikenal juga dengan nama atomic Attribute.

Composite Attribute, yaitu atribut yang terdiri dari beberapa komponen,

dimana masing-masing komponen memiliki keberadaan yang independen.

Misalkan atribut Address dapat terdiri dari Street, City, PostCode.

Single-Valued Attribute, yaitu atribut

yang mempunyai nilai tunggal untuk

setiap kejadian. Misalnya entitas Branch

memiliki satu nilai untuk atribut

BranchNo pada setiap kejadian.

Multi-Valued Atrribute, yaitu atribut yang mempunyai beberapa nilai untuk

setiap kejadian. Missal entitas Branch

memiliki beberapa nilai untuk atribut

telpNo pada setiap kejadian.

Derived Attribute, yaitu atribut yang memiliki nilai yang dihasilkan dari satu

atau beberapa atribut lainnya dan tidak harus berasal dari satu entitas.

2.1.4.4 Keys

Candidate key, yaitu jumlah minimal atribut-atribut yang dapat meng-

identifikasikan setiap kejadian / record secara unik.

Primary key, yaitu candidate key

yang dipilih untuk mengidentifikasikan setiap

kejadian/record dari suatu entitas secara unik.

Composite key, yaitu candidate key yang terdiri dari dua atau lebih atribut

Gambar 2.6 ER Diagram of Staff and Branch Entities and their Attributes

(Conolly, Database Systems. P382)

2.1.5

Normalisasi

Menurut Conolly (2010, p416) tujuan utama dalam pengembangan model

data logical pada sistem basis relasional adalah untuk menciptakan representasi

akurat suatu data, keterhubungannya dan batasan -

batasannya.Untuk mencapai

tujuan ini, maka harus ditetapkan/ diidentifikasi sekumpulan relasi.Empat bentuk

normal yang bisa digunakan yaitu, first normal form

(1NF), second normal form

(2NF) dan third normal form (3NF) dan Boyce-Codd normal form (BCNF). Terdapat

bentuk fourth normal form

(4NF) dan fifth normal form (5NF) untuk situasi yang

jarang terjadi.

Berdasarkan pada functional dependencies antar atribut dalam relasi. Sebuah

relasi dapat dinormalisasi kedalam bentuk tertentu untuk mengatasi kemungkinan

terjadinya pengulangan dari update yang tidak baik. Normalisasi adalah suatu teknik

untuk menghasilkan sekumpulan relasi dengan sifat-sifat

(properties) yang

diinginkan, memenuhi kebutuhan data pada enterprise.

Tahap-tahap Normalisasi antara lain;

1. Unnormalized form (UNF)

Unnormalized form adalah kondisi dimana sebuah table belum masuk

kedalam proses normalisasi atau disebut juga dengan bentuk awal dari table.

Menurut Connolly(2010,p30) Unnormalized form adalah suatu table atau form yang

masih memiliki isi yang berulang.

2. First Normal Form(1NF)

First Normal Form adalah bentuk normal pertama ini dapat dicapai bila telah

memenuhi syarat dimana setiap perpotongan baris dan kolom hanya memiliki satu

dan hanya satu nilai. Tahap 1NF bertujuan untuk mengidentifikasi dan

menghilangkan data yang bersifat repertisi didalam table.

3. Second Normal Form(2NF)

Second Normal Form adalah setelah setiap kolom hanya mengandung satu

dan hanya satu nilai,maka tahap selanjutnya dalam 2NF dengan memisahkan atribut

yang bersifat partially dependent

menjadi satu table yang berdiri sendiri.Jadi,tahap

2NF adalah tahap dimana satu table semua atribut bersifat fully dependent terhadap

primary key.

4. Thrid Normal Form(3NF)

Thrid Normal Form adalah setelah tahap 2NF data tetap memiliki sedikit

redudansi data maka tahap selanjutnya akan dilakukan tahap 3NF agar tidak ada

atribut yang bergantung dengan atribut primary key. Tahap 3NF adalah hubungan

hasil dari 1NF dan 2NF yang tidak ada atribut no-primary key yang bersifat transitif

dependent terhadap primary key. Jadi,pada tahap 3NF dilakukan untuk memisahkan

atribut-atribut yang brsifat transitif dependent . Konsep terpenting dalam keterkaitan

dengan normalisasi adalah Fungsional Dependencies.

5. BCNF(Boyce-Codd Normalized Form)

BCNF adalah tahap normalisasi dimana suatu relasi memenuhi syarat jika

hanya jika semua determinan adalah kunci kandidat.BCNF merupakan perbaikan

terhadap 3NF karena bentuk 3NF masih berkemungkinan memiliki anomaly.

2.1.5.1 Data Redudancy

Conolly (2010, p418) mengatakan bahwa tujuan utama dari desain basis data

relasional adalah untuk mengelompokkan atribut-atribut kedalam relasi-relasi

sehingga meminimalisasi redudansi data dan mengurangi penggunaan tempat

penyimpanan yang dibutuhkan oleh sebuah relasi dasar.Masalah –

masalah yang

terkait dengan redudansi dapat dijelaskan dengan membandingkan relasi Staff

dan

Branchdengan relasi StaffBranch.Relasi StaffBranch

memiliki data redudan, yaitu

detail dari Branch dituliskan berulang-ulang untuk setiap staff.Sebaliknya, informasi

mengenai Branch

muncul hanya satu kali pada relasi Branch dan hanya BranchNo

saja yang diulang dalam relasi Staff, untuk merepresentasikan dimana setiap staff

tersebut bekerja.

Gambar 2.7 Contoh Data Redudancy

(Conolly, Database Systems, p419)

2.1.5.2 Update Anomalies

Menurut Conolly (2010, p419) relasi yang mengandung informasi yang

redudan dapat diakibatkan oleh update anomalies. Beberapa tipe dari update

anomalies, diantaranya Insertion, Deletion, dan Modification.

2.1.5.3 Functional Dependency

Menurut Conolly (2010, p420) merupakan konsep inti yang terkait dengan

normalisasi.Functional dependency, menjelaskan relationship

antar atribut –atribut

dalam relasi. Misalkan, jika A dan B adalah atribut dari suatu relasi R, B dikatakan

Functionally Dependent

pada A (dinotasikan A

B), jika setiap nilai A

dihubungkan dengan tepat satu nilai B. (A dan B masing-masing dapat terdiri atas

satu atau lebih atribut). Functional dependency

merupakan sifat dari arti semantik

suatu atribut dalam sebuah relasi. Direpresentasikan dalam diagram:

Gambar 2.8 Contoh Functional dependency

(Conolly, Database Systems, p420)

Determinant

dari functional dependency

mengacu kepada atribut atau

himpunan atribut disebelah kiri anak panah.

Gambar 2.9 Contoh Functional dependency

(Conolly, Database Systems, p419)

Aturan Functional Dependencies (Armstrong’s Axioms):

Reflectivity

Jika B adalah bagian dari A, maka A

Augmentation

Jika A

B, maka A,C

B,C

Transitivity

Jika A

B dan B

C, maka A

Decomposition

Jika A

B,C, maka A

B dan A

Union

Jika A

B dan A

C, maka A

B,C

Composition

Jika A

B dan C

D, maka A,C

B,D

2.1.6

The Database System Development Life cycle

Database yang terintegrasi

tidak begitu saja terjadi tanpa dilakukan

perancangan, dalam membuat perancangan database

diperlukan metode

perancangan. Metode perancangan tersebut berupa siklus hidup, di mana dalam

merancang database perlu dilakukan sebuah perencanaan. Seperti yang dikemukakan

oleh Connolly & Begg (2010: 313)

yang mendefinisiskan bahwa “sistem database

merupakan komponen dasar sistem informasi dari perusahaan besar, sistem

pengembangan siklus database

secara melekat terkait dengan siklus hidup sistem

informasi”. Pentingnya untuk mengakui bahwa tahapan pengembangan siklus

database

tidak harus berurutan tetapi melibatkan beberapa jumlah pengulangan

tahapan sebelumnya melalui feedback loop.

“System development life cycle adalah metode tradisional yang digunakan

untuk mengembangkan, memelihara dan mengganti sistem informasi” (Hoffer,

Prescott, & Topi,2009: 85). Database System Development Life cycle ini merupakan

tahapaan siklus dalam perancangan database, di mana terdiri beberapa tahapan yang

dimulai dengan perencanaan, pengumpulan informasi hingga perancangan database.

Dari penjelasan di atas dapat diambil kesimpulan bahwa database system

development life cycle

berkaitan dengan siklus

hidup sistem informasi,

pengembangan database terdiri dari beberapa tahap dan bisa saja terjadi beberapa

pengulangan tahapan sebelumnya.

Gambar 2.10 The Database System Development Life cycle

(Sumber: Connolly & Begg, 2010: 314)

2.1.6.1 Database Planning

Dalam membangun sebuah database, tentunya diperlukan terlebih dahulu

suatu perencanaan agar masalah maupun resiko yang akan terjadi pada tahap

implementasi dapat dihilangkan ataupun diminimalisir.

Seperti yang dikemukakan oleh Connolly & Begg (2010: 313) “Database

planning

merupakan kegiatan manajemen yang memungkinkan tahapan dari siklus

hidup pengembangan sistem database

untuk direalisasikan seefisien mungkin.

Database

planning harus diintegrasikan dengan strategi sistem informasi dari

keseluruhan organisasi”. Ada tiga isu utama yang terlibat dalam merumuskan strategi

informasi, yaitu :

Identifikasi rencana dan tujuan perusahaan dengan penentuan kebutuhan

sistem informasi.

Evaluasi sistem informasi pada saat ini untuk menentukan kekuatan dan

kelemahan yang ada.

Menilai kesempatan atau peluang teknologi informasi yang mungkin

menghasilkan keuntungan kompetitif.

Dari penjelasan di atas, maka dapat disimpulkan bahwa Database planning

bertujuan untuk menentukan rencana-rencana dalam merancang sebuah database.

2.1.6.2 System Definition

Sebelum merancang suatu sistem database, hal utama yang dilakukan adalah

mengidentifikasi batas-batas dari sistem yang sedang diselidiki dan bagaimana

interface dengan bagian dari sistem informasi organisasi. Seperti yang didefinisikan

oleh Connolly & Begg (2010: 316) “System definition

menjelaskan ruang lingkup

dan batas-batas dari sistem database dan pendangan pengguna utama”.

Dari pengertian system definition dapat disimpulkan bahwa system definition

merupakan batasan-batasan dalam membuat database

yang diperlukan oleh

perusahaan. System definition

digunakan untuk mengidentifikasi scope

dari sistem

perusahaan.

2.1.6.2.1 User View

Sebelum melakukan perancangan database organisasi, langkah pertama yang

harus dilakukan adalah mengumpulkan informasi yang diperlukan oleh organisasi,

karena informasi merupakan hal yang penting dalam perancangan database.

Informasi merujuk pada apa yang diperlukan oleh pengguna database.

Seperti yang didefinisikan oleh Connolly & Begg (2010: 316) “User view

adalah mendefinisikan apa yang dibutuhkan dari sistem database

dari perspektif

peran pekerjaan tertentu (seperti manajer atau supervisor) atau area aplikasi

enterprise (seperti pemasaran, personalia atau kontrol stok)”.

Dapat disimpulkan bahwa sebelum melakukan perancangan database

diperlukan terlebih dahulu pengumpulan informasi-informasi yang dibutuhkan oleh

organisasi.

2.1.6.3 Requirements Collection and Analysis

Setelah menentukan sistem definisi, tahap selanjutnya adalah mengumpulkan

informasi yang diperlukan dan melakukan analisis data. “Requirements collection

and analysis adalah proses pengumpulan dan menganalisis informasi tentang bagian

dari organisasi yang harus didukung oleh sistem database

dan menggunakan

informasi untuk mengidentifikasi persyaratan untuk sistem baru” (Connolly & Begg,

2010: 316).

Dari pengertian Requirements collection and analysis dapat disimpulkan

bahwa Requirements collection and analysis bertujuan untuk mengumpulkan

kebutuhan-kebutuhan yang diperlukan oleh perusahaan dalam pengembangan

database dan menganalisis sistem perusahaan untuk mendukung sistem database.

2.1.6.4 Database Design

Setelah menentukan Requirements collection and analysis tahap selanjutnya

adalah perancangan database. Perancangan database

yang dilakukan berdasarkan

data yang telah dikumpulkan dan yang telah dianalisis. Pendekatan dalam

perancangan database terdiri dua pendekatan yaitu bottom-up dan top-down. Seperti

yang dikemukakan oleh Connolly & Begg (2010: 320-324)

“database design

merupakan proses menciptakan desain yang akan mendukung pernyataan misi dan

tujuan perusahaan pada sistem database

yang diperlukan”. Pendekatan desain

database ada dua yaitu bottom-up dan top-down. Pendekatan bottom-up dimulai pada

tingkat dasar atribut, yang melalui analisis asosiasi yang dikelompokkan ke dalam

hubungan yang mewakili jenis entitas dan hubungan antar entitas. Pendekatan

Buttom-up

tepat untuk digunakan mendesain database

sederhana dengan jumlah

yang atribut relatif kecil. Namun pendekatan ini akan menjadi sulit bila diterapkan

pada desain database yang lebih kompleks dengan jumlah atribut yang besar, dimana

sulit untuk membuat semua dependensi fungsional antara atribut.

Pendekatan Top-down dimulai dengan pengembangan model data yang berisi

entitas level tinggi dan hubungan kemudian berturut-turut diterapkan perbaikan Top-

down

untuk mengidentifikasi entitas tingkat bawah, hubungan, dan atribut yang

terkait. Pendekatan Top-down diilustrasikan dengan menggunakan konsep dari model

relasional entitas (ERD), dimulai dengan identifikasi entitas dan hubungan antara

entitas yang merupakan penting bagi organisasi.

Dalam merancang sebuah basis data dibutuhkan sebuah metodologi.

Metodologi perancangan basis data berguna untuk memudahkan dalam perancangan.

Seperti yang dikemukakan oleh Connolly & Begg (2010: 466) “Metodologi

perancangan basis data merupakan pendekatan terstruktur yang menggunakan

prosedur, teknik, tools

dan alat bantu dokumentasi untuk mendukung dan

memfasilitasi proses desain”. Metodologi perancangan harus dibuat secara pertahap

dari awal sampai akhir sesuai dengan struktur metodologinya. Metodologi

perancangan basis data terdiri dari tiga tahap yaitu :

Conceptual database design

Logical database design

Physical database design

2.1.6.4.1 Conceptual database design

Conceptual database design

merupakan tahap yang pertama dalam

metodologi perancangan database. Seperti yang dikemukakan oleh Connolly & Begg

(2010: 467)

“Conceptual database design

adalah proses membangun model data

yang digunakan dalam suatu perusahaan, yang terlepas dari semua pertimbangan

fisik (Physical)”. Pembuatan model konseptual berdasarkan proses bisnis yang

sedang berjalan pada suatu organisasi, sesuai dengan data-data apa yang dibutuhkan

oleh organisasi.

Conceptual database design memiliki beberapa langkah, yaitu :

Mengidentifikasi tipe entitas.

Untuk mengidentifikasi apa yang diperlukan oleh jenis entitas.

Mengidentifikasi tipe hubungan.

Untuk mengidentifikasi hubungan yang penting diantara tipe entitas

menentukan batasan multiplicity dari relationship.

a. Fan Traps

terjadi dimana model yang mempresentasikan suatu

hubungan dengan entitas,tetapi alur relasinya memperlihatkan ambiguitas.

b. Chasm

Traps terjadi dimana model menggambarkan keadaan dari

hubungan antar entitas yang satu dengan yang lain ,tetapi tidak ada

hubungan Antara kedua entitas yang utama.

Mengidentifikasi dan menghubungkan atribut dengan tipe entitas dan tipe

hubungan.

Untuk menghubungkan atribut sesuai dengan tipe entitas dan tipe

hubungan.

Menentukan atribut domain.

Untuk menentukan domain dari atribut di dalam model data konseptual.

Domain

adalah sebuah nilai dari satu atau lebih atribut yang

menggambarkan nilai dari atribut.

Menentukan atribut candidate, primary, dan alternate key.

Untuk mengidentifikasi candidate key pada setiap tipe entitas dan jika

lebih dari satu candidate key, pilih salah satu untuk menjadi primary key

dan yang lain sebagai candidate key.

Mempertimbangkan penggunaan tingkatan konsep pemodelan (langkah

tambahan).

Untuk mempertimbangkan penggunaan konsep pemodelan seperti

spesialisasi/generalisasi, agregasi dan komposisi.

Mengecek model yang redudansi.

Bertujuan untuk mengecek adanya redudansi dalam model. Tahap nya

ada 3 yaitu : Memeriksa kembali hubungan One-to-One

(1:1),

Menghilangkan hubungan yang redudansi, dan mempertimbangkan

dimensi waktu.

Memvalidasi model data konseptual terhadap transaksi pengguna.

Untuk memastikan model data konseptual mendukung transaksi yang

dibutuhkan.

Meninjau model data konseptual dengan pengguna.

Untuk meninjau model data konseptual dengan pengguna untuk

memastikan pertimbangan model “benar” yang merupakan reprensentasi

dari persyaratan data perusahaan.

2.1.6.4.2 Logical database design

Logical database design

merupakan tahap kedua dalam metodologi

perancangan database

setelah konseptual. ”Logical database design merupakan

suatu proses membangun model data yang digunakan dalam suatu perusahaan

berdasarkan pada model data yang spesifik, tetapi tidak tergantung pada DBMS dan

pertimbangan fisik lainnya” (Connolly & Begg, 2010: 467). Perancangan logikal

merupakan lanjutan dari perancangan konseptual, perancangan logikal ini

menjelaskan struktur informasi basis data serta aturan-aturan dalam proses

perancangan basis data.

Logical database design memiliki beberapa langkah, yaitu :

Mengambil hubungan dari model data konseptual.

Untuk membuat hubungan model data logikal untuk menyatakan entitas,

hubungan, dan atribut yang telah diidentifikasi. Pada tahap ini akan

ditentukan : Strong entity types, weak entity types, one-to-many

(1:*)

binary relationship types, one-to-one

(1:1) binary relationship types,

one-to-one

(1:1) recursive relationship types, superclass/subclass

relationship type, many-to-many (*:*) binary relationship types, complexs

relationship types, dan multi-valued attributes.

Memvalidasi hubungan dengan normalisasi.

Tujuan dari normalisasi untuk memastikan suatu hubungan paling sedikit

memerlukan atribut untuk mendukung kebutuhan data perusahaan.

Memvalidasi hubungan terhadap transaksi pengguna.

Untuk memastikan bahwa hubungan di dalam model data logikal

mendukung keperluan transaksi.

Mengecek integrity constraint.

Untuk mengecek apakah hambatan integritas menggambarkan model data

logikal. Ada 6 tipe integrity constraint :

Required data

Beberapa atribut harus mengandung nilai yang benar, dengan kata lain

setiap atribut tidak boleh kosong.

Attribute domain constraints

Setiap atribut memiliki domain, yaitu sekumpulan nilai atau values

yang sah.

Multiplicity

Multiplisitas mewaliki hambatan yang ditempatkan pada hubungan

antara data dalam database.

Entity integrity

Primary key dari sebuah entitas tidak boleh kosong.

Referential integrity

Jika foreign key

mengandung sebuah nilai atau value, nilai tersebut

harus mengacu pada tuple yang ada didalam relasi parent.

General constraint

Memperbaharui entitas yang dapat dikendalikan hambatan yang

mengatur transaksi dunia nyata diwakili oleh perbaharuan.

Meninjau data model logikal dengan pengguna.

Untuk meninjau data model logical dengan pengguna untuk memastikan

data model sesuai dengan pernyataan yang diperlukan oleh perusahaan.

Menggabungkan model data logikal kedalam model global (langkah

tambahan).

Menggabungkan model data logikal ke dalam model data logikal global

yang mewakili semua pengguna dari database.

Mengecek perkembangan yang akan datang.

Untuk menentukan apakah ada kemungkinan signifikan perubahan di

masa mendatang dan menilai apakah model data logical

dapat

mengakomodasi perubahan.

2.1.6.4.3 Physical database design

Physical database design

merupakan metodologi perancangan database yang

terakhir setalah logical database design. Setelah melakukan perancangan pada

logical database design

tahap selanjutnya adalah Physical database design.

“Physical database design adalah suatu proses menghasilkan sebuah gambaran yang

menunjukkan pelaksanaan database pada penyimpanan sekunder, menggambarkan

hubungan dasar, file

organisasi dan indeks yang digunakan untuk mencapai akses

yang efisien terhadap data, dan setiap integritas terkait dengan kendala dan tindakan

keamanan” (Connolly & Begg, 2010: 523). Perancangan fisik ini bertujuan untuk

menentukan struktur penyimpanan basis data pada suatu organisasi.

Pysical database design memiliki beberapa langkah, yaitu :

Menterjemahkan model data logical untuk sasaran DBMS.

Untuk menghasilkan hubungan skema database

dari model data logikal

dapat diimplementasikan ke dalam DBMS.

Merancang hubungan dasar.

Untuk memutuskan bagaimana untuk merepresentasikan identifikasi

hubungan dasar dalam model data logical dalam DBMS.

Merancang perwakilan atau representasi dari data yang diperoleh.

Untuk memutuskan bagaimana untuk merepresentasikan data yang

diperoleh dalam model data logikal dalam DBMS.

Merancang general constraints.

Untuk merancang general constraint ke dalam DBMS.

Merancang file organisasi dan indeks.

Menentukan file

organisasi yang optimal untuk menyimpan hubungan

dasar dan indeks yang diperlukan untuk mencapai kinerja yang dapat

diterima, yaitu cara dimana hubungan dan tuple

akan dilaksanakan pada

penyimpanan sekunder.

Menganalisis transaksi.

Untuk memahami fungsi dari transaksi yang akan berjalan pada

database dan untuk menganalisis transaksi yang penting.

Memilih file organisasi.

Untuk menentukan sebuah efisiensi file

organisasi untuk setiap

hubungan dasar.

Memilih indeks.

Untuk menentukan apakah penambahan indeks akan meningkatkan

performa sistem.

Mengestimasikan kapasitas kebutuhan.

Untuk memperkirakan jumlah kapasitas yang akan dibutuhkan oleh

database.

Merancang tampilan pengguna.

Untuk merancang tampilan pengguna yang diidentifikasi selama

pengumpulan kebutuhan dan menganalisis tahapan database system

development lifecycle.

Merancang mekanisme keamanan.

Untuk merancang mekanisme keamanan untuk database dispesifikasikan

selama pengumpulan kebutuhan dan pengumpulan tahapan dari database

system development lifecycle.

Dari pengertian database desisgn dapat disimpulkan bahwa database design

merupakan sebuah desain yang mendukung atau sesuai dengan misi dan tujuan yang

diperlukan oleh perusahaan.

2.1.6.5 DBMS Selection

Tahap ini digunakan untuk memilih DBMS yang sesuai untuk aplikasi

basisdata.Secara umum, DBMS adalah sebuah sistem perangkatlunak

yang

memperbolehkan pengguna untuk mendefinisikan (define), membuat (create),

memelihara (maintain), dan mengendalikan (control) akses ke basisdata (Connolly

dan Begg, 2010, p 312 - 329).

Umumnya, DBMS menyediakan fasilitas sebagai berikut:

Memperbolehkan pengguna untuk mendefinisikan basisdata melalui DDL

(DataDefinitionLanguage).

Memperbolehkan pengguna untuk menyisipkan (insert), memperbaharui

(update), menghapus (delete), dan mengambil (retrieve)

data dari

basisdata melalui DML (DataManipulationLangugage).

Menyediakan akses terkontrol ke basisdata, seperti:

Security Sistem (Sistem Keamanan)

Merupakan sistem untuk mencegah pengguna yang tidak berhak

untuk mengakses basisdata.

IntegritySistem (Sistem Integritas)

Merupakan sistem

untuk menjaga konsistensi dari data yang

tersimpan.

ConcurrencyControlSistem (Sistem Kontrol Konkurensi)

Merupakan sistem untuk

memperbolehkan akses terbagi pada

basisdata.

RecoveryControlSistem (Sistem Kendali Pemulihan)

Merupakan sistem untuk memulihkan data ke keadaan semula jika

terjadi kegagalan.

User-AccessibleCatalog (Katalog untuk pengguna)

Merupakan sistem

yang menjelaskan gambaran data di dalam

basisdata.

Langkah-langkah utama dalam memilih DBMS :

Mendefinisikan faktor-faktor yang menunjang penelitian dalam

memilih DBMS

Membuat daftar pilihan produk-produk DBMS yang akan

digunakan

Mengevaluasi produk-produk yang berada pada daftar

Memilih produk DBMS dan membuat laporannya

2.1.6.6 Application Design

Conolly & Begg (2010, p329) Tahap ini bertujuan untuk merancang

antarmuka pengguna dan program aplikasi yang menggunakan dan mengolah

basisdata. Dua aspek yang penting pada tahap perancangan aplikasi yaitu :

2.1.6.6.1 Transaction Design

Tujuan dari perancangan transaksi adalah untuk mendefinisikan dan

mendokumentasikan karakteristik-karakteristik tingkat tinggi dari transaksi yang

dibutuhkan pada basisdata, yang meliputi :

Data yang akan digunakan oleh transaksi

Karakteristik fungsional dari transaksi

Output transaksi

Kepentingan pengguna

Nilai pemakaian yang diharapkan

Aktivitas ini harus dikerjakan pada awal proses desain untuk memastikan bahwa

basisdata yang diimplementasikan dapat mendukung semua transaksi yang

dibutuhkan.

2.1.6.6.2 User Interface Design

Sebelum mengimplementasikan form atau laporan, diperlukan perancangan

layoutnya. Beberapa pedoman dalam merancang form atau laporan :

Penggunaan judul yang jelas dan tidak ambigu

Penggunaan instruksi-instruksi yang dapat dipahami

Pengelompokan dan pengurutan field-field pada form atau laporan

Penggunaan layout form atau laporan yang menarik dan atraktif

Penggunaan label field yang sudah lazim

Pemakaian terminologi dan singkatan yang konsisten

Pemakaian warna yang konsisten

Batasan-batasan dan ruang yang tampak jelas pada field

Pergerakan kursor yang nyaman

Pembetulan kesalahan untuk karakter tunggal maupun seluruh fields

Penampilan pesan kesalahan untuk nilai yang tidak sesuai

Kejelasan pada field yang optional

Adanya pesan yang dapat menjelaskan untuk field-field yang ada

Adanya pemberitahuan jika proses pengisian field dalam form telah selesai

2.1.6.7 Prototyping(optional)

“Prototyping merupakan sebuah model kerja yang biasanya tidak memiliki

semua fitur yang diperlukan atau

member semua fungsi dari sistemfinal”(Conolly &

Begg, 2010, p333) Tahap prototyping

bertujuan untuk membangun sebuah model

kerja dari aplikasi basisdata yang mengijinkan perancang atau pengguna untuk

memvisualisasi dan mengevaluasi bagaimana fungsi dan tampilan sistem pada tahap

akhir. Strategi-strategi untukprototyping :

Requirements Prototyping

Prototyping jenis ini menggunakan sebuah prototype untuk

menentukan kebutuhan dari aplikasi basisdata yang diminta, dan setelah

kebutuhan itu terpenuhi, prototype tidak digunakan lagi.

Evolutionary Prototyping

Prototyping jenis ini menggunakan sebuah prototype untuk

menentukan kebutuhan dari aplikasi basisdata yang diminta, dan setelah

kebutuhan itu terpenuhi, prototype dikembangkan untuk menjadi aplikasi

basisdata yang berfungsi.

2.1.6.8 Implementation

“Tahap implementasi merupakan tahap realisasi dari perancangan aplikasi

dan basisdata secara fisik dari database dan desain aplikasi” (Conolly & Begg, 2010

,p333). Implementasi basisdata ini dapat dicapai dengan menggunakan Data

Definition Language (DDL) dari DBMS yang dipilih.Statement-statement pada DDL

digunakan untuk membentuk struktur basisdata dan filebasisdata yang masih kosong.

Transaksi basisdata, yang merupakan bagian dari program aplikasi,

diimplementasikan menggunakan Data Manipulation Language (DML) dari DBMS

tujuan.

2.1.6.9 Data Conversion and Loading

“Data Convertion and Loading didefinisikan sebagai mentransfer data yang

ada ke dalam database

baru dan mengkonversi setiap aplikasi yang ada untuk

menjalankan database baru”(Conolly & Begg, 2010, p334). Tahap ini berguna untuk

memasukkan atau mengkonversi data dari sistem lama ke sistem yang baru sehingga

dapat berjalan pada basisdata yang baru.Tahap ini dibutuhkan hanya bila sistem

basisdata yang baru digunakan untuk menggantikan sistem yang lama.

2.1.6.10 Testing

Conolly & Begg (2010, p334) mengemukakan bahwa testing merupakan

sebuah proses menjalankan sistem database

dengan maksud untuk menemukan

kesalahan. Pada tahap ini, aplikasi basisdata diujicoba untuk mencari error dan

divalidasi terhadap kebutuhan yang telah dispesifikasi pengguna.

2.1.6.11 Operational maintenance

Tahap ini merupakan proses untuk mengawasi dan memelihara sistem.

“Operational maintenance merupakan sebuah proses pemantauan dan pemeliharaan

sistem database” (Conolly & Begg, 2010 ,p335). Aktivitas-aktivitas yang dilakukan

antara lain :

Mengawasi kinerja sistem

Jika kinerja sistem berada di bawah tingkat yang dapat diterima,

pengubahan ulang atau reorganisasi basisdata mungkin dibutuhkan.

Memelihara dan meningkatkan aplikasi basisdata (jika dibutuhkan)

Kebutuhan baru digabungkan ke dalam aplikasi basisdata melewati tahap-

tahap sebelumnya dari daur hidup yang ada.

2.1.7 Unified Modeling Language (UML)

Dalam merancang sistem yang baik dan benar diperlukan suatu metode analisis

sistem dimana terdiri dari kaidah-kaidah serta aturan-aturan model dan notasi

berbasis pada object-oriented. Menurut Satzinger,Jackson,dan Burd

(2010.p240),unified

modeling language (UML)merupakan serangkaian standar

konstruksi model dan notasi secara khusus dirancang untuk pengembangan object –

oriented.Jenis-jenis sistem model dari komponen sistem yang menggunakan

UML,meliputi:

Data Flow Diagram(DFD)

Entity Relationship Diagram(ERD0

Activity Diagram

Use Case Diagram

Use Case Description

Update Class Diagram

Sequance Diagram

Communication Diagram

User Interface

2.1.7.1 User Interface

Antarmuka pengguna melibatkan input

dan output

yang lebih langsung

melibatkan pengguna sistem atau bisa dikatakan sebagai interaksi antara

pengguna.Menurut Satzinger,Jackson, dan Burd (2010,p531) user interface

merupakan bagian dari sistem informasi yang membutuhkan interaksi pengguna

sistem untuk membuat input

dan output

sistem.pada saat pengguna menggunakan

sistem tersebut,pengguna memiliki tiga aspek user interface,yaitu:

Aspek Fisik User Interface

Sebuah User Interface yang termaksud perangkat-perangkat yang dapat

disentuh secara langsung oleh user,termaksud keyboard,mouse,touch screen,atau

keypad.

Aspek Perseptual User Interface

Sebuah user interface yang dapat dilihat, didengar, maupun disentuh (tidak

secara fisik) oleh end user. Yang dapat dilihat termasuk data dan instruksi yang

ditampilkan pada layar, termasuk bentuk-bentuk, garis, nomor,dan kata-kata.

Aspek Konseptual User Interface

User interface

yang diketahui oleh end user

mengenai penggunaan sistem,

termasuk dalam hal-hal yang terjadi di dalam problem domain

pada sistem yang

dimanipulasi oleh user, operasi-operasi yang dapat dijalankan, dan prosedur-

prosedur yang ditaati dalam menjalankan operasi.

2.1.8

Panduan dalam Perancangan Layar Antarmuka (Guidelines For

Designing User Inteface)

2.1.8.1 Standar Perancangan Antarmuka (Interface Design Standards)

Di dalam merancang sebuah sistem diperlukan suatu layar antarmuka antara

sistem dengan pengguna dengan tujuan untuk memudahkan interaksi antara sistem

dengan pengguna sistem. Layar antarmuka dirancang sedemikian

rupa untuk

memenuhi standarisasi layar antarmuka yang baik dan benar. Menurut Satzinger,

Jackson, dan Burd (2010, p540), standar perancangan antarmuka (Interface Design

Standards) adalah prinsip dan aturan umum yang harus diikuti untuk membuat

interface atau antarmuka dari setiap sistem yang dikembangkan oleh perusahaan atau

organisasi.

2.1.8.2 Delapan Aturan Emas (Eight Golden Rules)

Dalam merancang sebuah user interface tentu tidak lepas dari kaidah –

kaidah penulisan serta aturan yang baik untuk menghasilkan user interface yang baik

pula. Hal ini diperkuat Satzinger, Jackson, dan Burd

(2010, p541) yang mengatakan

bahwa ada delapan aturan emas (eight golden rules). Delapan aturan

ini digunakan

untuk merancang layar antarmuka yang interaktif dan mendukung

fungsi kegunaan.

Contoh dapat dilihat pada gambar 2.11

Gambar 2.11 Eight Golden Rules

Sumber : Satzinger, Jackson, dan Burd (2010, p541)

Penjelasan gambar 2.22 Eight Golden Rules adalah sebagai berikut:

Berusaha untuk konsistensi (strive for consistency).

Merancang konsistensi penampilan dan antarmuka yang fungsional

merupakan salah satu tujuan perancangan yang sangat penting . Pengaturan

informasi yang diatur di dalam form, nama, serta pengaturan item –

item

menu, ukuran dan bentuk ikon – ikon serta alur dari sistem harus konsisten.

Memungkinkan pengguna yang sering menggunakan sistem untuk

menggunakan jalan pintas (Enable Frequent Users to Use Shortcuts).

Umumnya pengguna yang sudah sering menggunakan aplikasi lebih

menginginkan kecepatan dalam mengakses informasi yang diinginkan. jadi

tingkat interaksi yang diminta lebih pendek / singkat dan langsung menunjuk

fungsi tersebut tanpa melewati alur menu yang panjang dan kotak dialog yang

ganda. Shortut keys berfungsi untuk mengurangi jumlah interaksi pengguna

sistem dengan sistem untuk meringankan tugas pengguna sistem.

Memberikan atau menawarkan umpan balik yang informatif (Offer

Informative Feedback).

Umpan balik harus diberikan untuk memberikan informasi kepada

pengguna sesuai dengan aksi yang dilakukannya. Pengguna akan mengetahui

aksi apa yang telah dan akan dilakukan dengan adanya umpan balik. Umpan

balik biasanya berupa konfirmasi, informasi atau suatu aksi.

Merancang dialog untuk menghasilkan penutupan (Design Dialogs to Yield

Closure).

Urutan tindakan sebaiknya diorganisir atau diatur di dalam suatu

kelompok bagian awal, tengah dan akhir. Umpan balik yang diberikan akan

memberitahukan pengguna sistem bahwa tindakan yang dilakukan sudah

benar dan dapat melanjutkan sejumlah tindakan berikutnya.

Memberikan penanganan kesalahan yang sederhana (Offer Simple Error

Handling).

Sistem dirancang untuk mencegah pengguna sistem agar tidak

melakukan kesalahan fatal. Jika kesalahan fatal tersebut terjadi, maka sistem

dapat langsung memberikan pencegahan kesalahan dengan cepat dan

memberikan mekanisme yang simpel dan mudah dipahami oleh pengguna

sistem.

Mengijinkan kemudahan untuk kembali ke tindakan sebelumnya (Permit

Easy Reversal of Actions).

Sistem dirancang bagi pengguna untuk tidak menyulitkan pengguna.

Pengguna sistem dibuat untuk tidak takut akan pilihan menu -

menu baru

karena adanya menu undo

atau back

dimana memungkinan pengguna untuk

melakukan tindakan kembali jika salah melakukan tindakan.

Mendukung tempat pengendalian internal (Support Internal Locus of

Control).

Pengguna sistem merupakan pengendali utama terhadap sistem yang

ada, bukan sistem yang mengendalikan pengguna jadi pengguna mengontrol

sistem utama terhadap menu – menu yang ada.

Mengurangi beban ingatan jangka pendek (Reduce Short-Term Memory

Load).

Pengguna tidak disulitkan dengan menu –

menu yang banyak di

dalam sistem atau aplikasi sehingga pengguna dapat melakukan tindakan

dengan memilih menu yang simpel tanpa harus mengingat semua perintah

atau fungsi menu – menu sistem.

2.1.9 Keuntungan Database Management Sistem (DBMS)

Penggunaan database management sistem dapat memberikan keuntungan

pada pengguna, keuntungannya adalah :

Mengontrol redudansi data, sistem basis file

tradisional menyimpan

informasi yang sama di dalam beberapafile, pendekatan database

digunakan untuk menghilangkan redudansi data dengan mengintegrasikan

file sehingga beberapa salinan data yang sama tidak disimpan.

Konsistensi data, dengan menghilangkan atau mengendalikan redudansi

berarti mengurangi

resiko tidak konsistensi yang terjadi. Jika data

disimpan hanya sekali dalam database setiap update nilai harus dilakukan

hanya sekali dan nilai baru yang tersedia langsung digunakan untuk user,

jika data yang disimpan lebih dari satu kali dan sistem meyadari hal ini

maka sistem dapat memastikan bahwa semua salinan data yang disimpan

harus konsisten.

Informasi lebih lanjut dari jumlah data yang sama, dengan integrasi data

operasional memungkinkan organisasi untuk mengarahkan informasi

tambahan dari data yang sama.

Berbagi data, biasanya file

yang dimiliki oleh satu orang atau departemen

yang menggunakannya, di sisi lain database

dimiliki oleh seluruh

organisasi dan dapat digunakan bersama oleh semua pihak yang

berwenang.

Meningkatkan integritas data, integritas database

mengacu pada validasi

dari konsistensi data yang tersimpan, Integritas biasanya dinyatakan

dalam hal kendala yaitu konsistensi aturan di mana database

tidak

diperbolehkan untuk melakukan pelanggaran.

Meningkatkan keamanan, keamanan database

merupakan melindungi

database dari pengguna yang tidak sah atau unauthorized user.

Menegakkan standar, integrasi memungkinkan DBA untuk

mendefinisikan dan DBMS menegakkan standar yang diperlukan,

memungkinkan departemen, organisasi, standar nasional atau

internasional untuk hal seperti format data untuk memfasilitasi pertukaran

data antara sistem, penamaan conventions, standar dokumentasi, prosedur

update dan aturan akses.

Skala ekonomi, menggabungkan semua data operasional organisasi atau

perusahaan ke dalam satu database dan menciptakan suatu aplikasi yang

bekerja pada satu sumber data yang dapat memberikan penghematan

biaya.

Neraca persyaratan yang saling bertentangan, setiap pengguna atau

departemen memiliki kebutuhan yang mungkin bertentangan dengan

kebutuhan pengguna lain karena database berada dibawah kendali DBA,

DBA dapat membuat keputusan tentang penggunanaan desain dan

operasional database

memberikan sumber daya yang baik bagi pengguna

dan organisasi secara keseluruhan.

Meningkatkan aksesibilitas data dan responsif, hasil dari integrasi data

yang melintasi batas-batas departemen adalah diakses langsung oleh

pengguna akhir.

Meningkatkan produktivitas, DBMS menyediakan banyak fungsi standar

yang biasanya programmer harus menulis di dalam aplikasi berbasis file.

Meningkatkan pemeliharaan melalui independensi data, dalam sistem

berbasis file, gambaran data dan logika untuk mengakses data yang

dibangun kedalam setiap program aplikasi membuat program bergantung

pada data.

Meningkatkan konkurensi, dalam beberapa sistem berbasis file

jika ada

dua atau lebih pengguna yang diizinkan untuk mengakses rule yang sama

secara bersamaan adalah mungkin bahwa akses akan mengganggu satu

sama lain, sehingga kehilangan informasi atau bahkan hilangnya

integritas.

Meningkatkan backup dan pemulihan layanan, banyak sistem berbasis file

menempatkan tanggung jawab pada pengguna untuk memberikan ukuran

untuk melindungi data dari kegagalan untuk sistem komputer atau

program aplikasi.

2.1.10 Kekurangan DatabaseManagement Sistem (DBMS)

Kekurangan-kekurangan database management sistem adalah sebagai

berikut:

Kompleksitas, kompleksitas dapat menyebabkan kegagalan untuk memahami

sistem dapat menyebabkan keputusan yang buruk yang dapat memliki

konsekuensi serius bagi suatu organisasi.

Ukuran, kompleksitas dan luasnya fungsi membuat ukuran DBMS menjadi

sangat besar untuk suatu software, DBMS dapat menampati megabyte

dari

disk dan membutuhkan sejumlah memori yang besar agar dapat berjalan

secara efisien.

Biaya dari DBMS sangat bervariasi dan tergantung pada lingkungan dan

fungsi yang disediakan oleh DBMS.

Biaya tambahan untuk perangkat keras, DBMS memerlukan disk dalam

penyimpanan dan memungkinkan pembelian ruang penyimpanan tambahan.

Biaya konversi, dalam beberapa situasi biaya dari DBMS dan perangkat keras

relatif kecil dibandingkan dengan biaya mengkonversi aplikasi untuk

beroperasi dalam DBMS baru dan perangkat keras.

Kinerja, DBMS ditulis lebih umum untuk melayani aplikasi bukan hanya satu

tapi lebih dari satu.

Dampak yang besar untuk gagal, sentralisasi sumber daya meningkat

kerentanan dari sistem karena semua pengguna dan aplikasi bergantungan

pada ketersediaan DBMS, kegagalan komponen tertentu dapat membawa

operasi berhenti

2.1.11 VB.NET

Menurut Deitel (2001, p7-8),

Visual Basic. NET berevolusi dari BASIC

(Beginner’s All-Purpose Symbolic Instruction Code), dikembangkan pada

pertengahan 1960-an oleh Profesor John Kemeny dan Thomas Kurtz dari Dartmouth

College sebagai bahasa untuk menulis program sederhana. Pada awal didirikannya

Microsoft Corporation oleh Bill Gates, ia mulai menerapkan BASIC pada beberapa

komputer pribadi. Seiring dengan pengembangan antarmuka pengguna pada GUI

dari Microsoft Windows di akhir tahun 1980 dan awal 1990-an, evolusi BASIC

adalah Visual Basic, yang diperkenalkan Microsoft pada tahun 1991.

Adanya kemajuan alat pemrograman dan perangkat elektronik menciptakan

banyak tantangan, sehingga para pengembang menyadari bahwa klien mereka tidak

hanya dibatasi pada aplikasi desktop

dan kebutuhan komponen untuk berinteraksi

melalui internet pun meningkat secara dramatis.

Untuk mengatasi kebutuhan ini, Microsoft mengumumkan pengenalan

Microsoft. NET (Diucapkan "dot-net") strategi pada tahun 2000. Platform. NET

adalah salah satu dari yang berbasis Web aplikasi dapat didistribusikan ke berbagai

perangkat (seperti ponsel) dan ke desktop

komputer. Platform .NET menawarkan

model pemrograman baru yang memungkinkan program yang dibuat dalam bahasa

pemrograman yang berbeda untuk berkomunikasi satu sama lain. Selain itu, dengan

adanya .NET yang sangat penting untuk strategi Microsoft .NET, pengembang juga

dapat bermigrasi dari Visual Basic dengan lebih mudah.

Visual Basic .NET yang dikenal sebagai VB.NET adalah suatu bahasa

pemrograman komputer berorientasi objek yang diimplementasikan pada Framework

.NET.

Microsoft telah merancang versi Visual Basic untuk .NET dengan

kemampuan berorientasi obyek, dimana pada versi Visual Basic sebelumnya tidak

ada. Visual Basic .NET menawarkan orientasi objek yang ditingkatkan sehingga

memungkinkan programmer untuk mengembangkan aplikasi dengan lebih cepat.

Visual Basic. NET merupakan event-driven, bahasa pemrograman visual

dimana program yang dibuat menggunakan Integrated Development Environment

(IDE). Dengan IDE, programmer dapat

menulis, jalankan, menguji dan men-debug

program Visual Basic nyaman, sehingga mengurangi waktu yang dibutuhkan untuk

menghasilkan program kerja untuk sebagian kecil dari waktu itu akan diambil tanpa

menggunakan IDE.

Visual Basic. NET juga memungkinkan adanya peningkatan bahasa

interoperability

yaitu komponen software

dari bahasa yang berbeda dapat

berinteraksi dengan yang belum pernah sebelumnya. Di samping itu, VB.NET juga

memungkinkan pengguna untuk berinteraksi melalui internet, dengan menggunakan

standar industry seperti Simple Object Access Protocol

(SOAP) dan XML. Dengan

adanya kemajuan tersebut, gaya pemrograman baru akan muncul dimana aplikasi

yang dibuat dari komponen yang disebut Web Services tersedia melalui internet.

2.1.12 Postgre SQL

PostgreSQL adalah sebuah sistem basis data yang disebarluaskan secara

bebas menurut perjanjian lisensi BSD. Piranti lunak ini merupakan salah satu basis

data yang paling banyak digunakan saat ini, selain MySQL dan Oracle. PostgreSQL

menyediakan fitur yang berguna untuk replikasi basis data. Fitur-fitur yang

disediakan PostgreSQL antara lain

DB Mirror, PGPool, Slony, PGCluster, dan lain-

lain.

Tipe-tipe data:

1.Char(n): Mendifinisikan string sepanjang n karakter. Bila n tidak didefinisikan

maka n adalah 1.

2.Varchar(n): Mendifinisikan string sepanjang variable n.

3.Binnary(n): Untuk menyimpan bit pattern seperti heksadicemal.Contoh

:0x0fa9008e

4.Datetime:Mendefinisikan tanggal,menyimpan tahun,bulan,hari,jam,menit,detik

dan seperseribu detik.

5.Money: Bilangan pecahan dengan 4 angka dibelakang koma.Digunakan untuk

perhitungan moneter.

6.Int: Mendefinisikan integer,bilangan bulatyang menampung angka sebanyak

4byte.

2.2

Teori-Teori Khusus

2.2.1 Telemarketing

Telemarketing merupakan sebuah cara dalam bidang pemasaran yang

menggunakan teknologi telekomunikasi sebagai bagian dari program pemasaran

yang teratur dan terstruktur. Telemarketing (pemasaran jarak jauh) adalah

penggunaan telepon dan pusat panggilan (call center) untuk menarik prospek kepada

konsumen, menjual kepada pelanggan yang telah ada dan menyediakan layanan

dengan mengambil pesanan dan menjawab pertanyaan melalui telepon.

Telemarketing membantu perusahaan dalam meningkatkan pendapatan, mengurangi

biaya penjualan, meningkatkan kepuasan pelanggan (Kotler, 2009, p245)

Maka dapat dikatakan bahwa telemarketing merupakan sebuah telepon

sebagai sebuah media untuk melakukan direct marketing

sehingga berbagai macam

penjualan dan aktivitas penelitian pasar dapat dilaksanakan. Apabila memilik sisitem

informasi yang baik dan terstruktur maka telemarketing dapat melakukan kontak

yang terkomputerisasi dengan pelanggan yang potensial dan menjaga agar kontak

tersebut menguntungkan.

2.2.2 Konsep Telemarketing

Kelly Holden (2004, p4), memiliki konsep kerja sistem pada telemarketing

terbagi dalam 3 bagian, yaitu:

Mengetahui siapa yang akan di telepon

Melakukan panggilan telepon

Menelepon kembali jika calon pelanggan berhalangan

2.2.3 Jenis-Jenis Telemarketing

2.2.3.1 Inbound Telemarketing

Merupakan panggilan telepon yang dilakukan oleh pelanggan

dan calon

pelanggan yang cukup tertarik dengan produk atau jasa yang ditawarkan. Selama

panggilan, telesales

akan menginformasikan tentang pesanan atau mencoba untuk

memperbanyak pesanan pelanggan dan calon pelanggan dengan menyarankan

produk –

produk pelengkap lainnya. Program ini sukses dibentuk dengan perhatian

khusus pada factor-faktor seperti jenis pelayanan telepon yang dipilih, penyedia

layanan, dan perancangan periklanan yang menggunakan nomor telepon (Kotler,

2009, p246)

2.2.1.3.2 Outbound Telemarketing

Tujuan dari kebanyakan panggilan telepon dengan jenis telemarketing ini

adalah untuk menjual produk atau jasa kepada pelanggan baru maupun yang sudah

ada.Outbound telemarketing dilakukan melalui telepon untuk memancing pelanggan

membeli produk ataupun menanyakan kondisi pelanggan yang menggunakan produk

untuk meningkatkan penjualan dan mengerti permintaan pelanggan. Jenis

telemarketing ini juga dapat digunakan untuk memberitahukan pelanggan tentang

penundaan pengiriman barang karena faktor-faktor yang tak terduga, masalah yang

mungkin terjadi dalam pemesanan barang ataupun untuk mengetahui ketertarikan

pelanggan pada produk atau jasa yang ditawarkan (Kotler,2009, p246).

2.2.4 Penggunaan Basisdata dalam telemarketing

Mengembangkan sebuah basisdata tentang pelanggan yang mendasar

merupakan hal yang sangat penting.Peningkatan-

peningkatan yang kreatif pada

basisdata dapat meningkatkan efisiensi telesales

secara dramatis.Hal penting yang

pertama kali harus dilakukan adalah menentukan data-data yang harus dimasukkan

kedalam basisdata tersebut.Kebutuhan basisdata dapat bermacam-macam sesuai

dengan kategori bisnis maupun tipe dari pelanggan yang dituju.

Untuk para telemarketer, sumber utama dari data adalah laporan dari

panggilan yang dilakukan. Laporan panggilan ini harus mencakup sejarah dari tiap

account beserta pengarahan pada layanan di masa yang akan datang. Data-data yang

perlu dimasukkan kedalam basisdata antara lain:

Kontak utama dari pelanggan

Alamat pengiriman barang maupun surat

Batasan kredit pelanggan

Pola pembelian pelanggan saat ini

Sejarah pembelian pelanggan untuk produk atau layanan tertentu

Kebutuhan-kebutuhan pelanggan tertentu

Waktu terbaik untuk melakukan panggilan

Sumber –sumber dalam mendapatkan kontak utama

Catatan – catatan pribadi

Siklus panggilan untuk follow-up

Dengan data-data tersebut tersimpan dalam komputer, melakukan

percakapan yang berarti dengan pelanggan akan menjadi lebih mudah. Komputer

memastikan telesales

memperoleh daftar panggilan follow-up

yang terjadwal setiap

hari. Sebelum melakukan setiap panggilan, data-data pelanggan dapat dilihat dilayar

komputer, sehingga telesales

mendapatkan gambaran tentang pelanggan yang akan

dihubungi. Meskipun telesales

memiliki ratusan atau bahkan ribuan data-data

pelanggan, telesales

dapat memiliki pengetahuan yang banyak dalam percakapan

dengan pelanggan secara spesifik (tsai, 1995)

2.2.5 Penggunaan Apliaksi Perangkat Lunak Dalam Telemarketing

Menurut Venkat Rajan Balasubramanian (2003, p1), tugas telesales

yang

bermacam-macam mulai dari melakukan panggilan ke calon pelanggan,

mengumpulkan informasi, dan menelepon kembali calon pelanggan, mengumpulkan

informasi, dan menelepon kembali calon pelanggan yang meminta untuk ditelepon

ulang, maka diperlukannya perangkat lunak yang dapat meningkatkan efisiensi

telesales dan menyediakan fasilitas bagi manager untuk mengawasi kinerja telesales.

Kriteria pemilihan dan penggunaan perangkat lunak dalam telemarketing

(Balasubramanian, 2003, p2) antara lain meliputi ketahanan (robustness), kemudahan

(ease of use), kinerja (Performance), stabilitas, skalabilitas, fleksibilitas, dan biaya.

2.2.6 Kerangka Berpikir

Dalam merancang sistem basis data pada PT.DNN, penulis menyusun suatu

kerangka berpikir yang terdiri atas beberapa bagan. Kerangka

berpikir yang

digunakan dalam merancang sistem basis data pada PT.DNN menggunakan teori

Connolly & Begg (2010) yaitu

The Database System Development Life cycle.

Database System Development Life cycle merupakan sebuah perencanaan basis data

dengan menentukan mission statement dan mission objective, system definition yaitu

menentukan batas-batasan sistem dalam perancangan basis data, database design

atau perancangan basis data yang terdiri dari tiga metodologi yaitu konseptual,

logikal dan fisikal, kemudian

menentukan tempat penyimpanan basis datanya.

Pengumpulan kebutuhan dan informasi yang dibutuhkan oleh organisasi dalam

merancang basis data, melakukan implementasi sistem basis data yang dirancang,

melakukan konversi data ke dalam basis data baru, melakukan testing pada basis data

dan aplikasinya dan yang terakhir adalah melakukan maintenance

untuk memelihara

atau menjaga performa basis data.

Gambar 2.12 Bagan Kerangka Berpikir