2012100617SIBab2

BAB 2

LANDASAN TEORI

2.1 Database

Menurut Connoly dan Begg (2010, p65), database adalah kumpulan data yang

saling

berhubungan

secara

logikal

serta

deskripsi

dari

data tersebut,

yang

dirancang

untuk memenuhi kebutuhan informasi suatu organisasi.

Menurut Kroenke dan Auer (2010, p8), database adalah kumpulan data yang

saling berhubungan dan struktur lainnya.

Dari

definisi

atas

dapat

disimpulkan

bahwa

database

adalah

suatu tempat

penyimpanan data yang saling berhubungan dan struktur lainya beserta dengan deskripsi

data tersebut yang dirancang untuk memenuhi kebutuhan informasi.

2.2 Database System

Menurut Date

(2004, p6), database system adalah

sistem terkomputerisasi

yang

memiliki

yang

secara

keseluruhan

memiliki

tujuan

untuk

menyimpan

informasi

dan

untuk

memperbolehkan

pengguna

untuk

mendapatkan kembali dan

meng-update

informasi sesuai dengan yang diinginkan.

Dari

definisi

atas dapat

disimpulkan bahwa sistem basis

data

adalah

suatu

aplikasi yang terhubung dengan basis

data yang digunakan untuk menyimpan serta

mengubah

informasi dalam basis data sesuai dengan kepentingan

masing-masing

pengguna yang berkepentingan.

2.3 Database Management System (DBMS)

Menurut Connolly dan Begg (2010, p6), database management system adalah

sistem perangkat lunak yang memungkinkan pengguna dapat mendefinisikan, membuat,

merawat, dan mengatur akses ke basis data.

Menurut Kroenke dan

Auer

(2010, p8),

database

management system

adalah

program komputer yang digunakan untuk membuat proses dan mengelola database.

Menurut Date (2001, p43), database management system adalah perangkat lunak

yang menangani semua akses ke database.

Dari definisi di

atas dapat disimpulkan

bahwa

DBMS adalah

perangkat lunak

yang digunakan untuk membuat, mengelola data, dan mengatur hak akses user terhadap

objek yang ada di dalam basis data.

2.3.1 Komponen lingkungan Database Management System(DBMS)

Menurut

Connolly

dan Begg

(2010,

p68-71),

5 komponen

utama

pada

lingkungan DBMS adalah Hardware, software, data, prosedur, dan manusia.

Gambar 2.1 komponen DBMS Environtment

(Sumber: Connolly Dan Begg, 2010, p68)

Hardware

DBMS dan aplikasinya memerlukan perangkat keras agar dapat berjalan. Perangkat

keras

dapat

terdiri

dari

single

personal

computer,

single mainframe,

atau

sebuah

jaringan komputer. Beberapa DBMS hanya dapat berjalan pada perangkat keras atau

sistem operasi

tertentu, sedangkan DBMS

lainnya

dapat

berjalan

pada

bermacam-

macam perangkat keras atau sistem operasi.

2. Software

Komponen perangkat lunak terdiri dari perangkat

lunak DBMS dan program

aplikasi, dengan sistem operasi, termasuk di dalamnya perangkat lunak jaringan jika

DBMS digunakan dalam sebuah

jaringan. Pada

umumnya, program aplikasi ditulis

dalam bahasa pemrograman

generasi

ketiga

(3GL) seperti ‘C’,

C++,

Java,

Visual

Basic, COBOL, Fortran, Ada, or Pascal, atau bahasa pemrograman generasi keempat

(4GL),

seperti SQL,

yang juga terdapat dalam pada bahasa pemrograman

generasi

ketiga.

3. Data

Data merupakan komponen yang penting dalam DBMS, terutama dari sudut pandang

pengguna akhir. Data menghubungkan komponen mesin (hardware) dengan

manusia. Sebuah basis data berisi data operasional dan meta-data, yaitu data yang

menjelaskan data.

4. Procedures

Prosedur merupakan sekumpulan instruksi dan aturan yang mengatur rancangan dan

penggunaan dari basis data. Pengguna sistem dan staff yang

mengelola basis data

membutuhkan sebuah prosedur yang didokumentasikan tentang penggunaan sistem.

Mencakup instruksi-instruksi:

• Log on ke DBMS

• Menggunakan fasilitas DBMS program aplikasi tertentu.

•

Memulai dan mengakhiri DBMS.

•

Membuat duplikat back-up basis data.

•

Menangani kerusakan perangkat keras atau perangkat lunak.

•

Mengubah struktur table, mengatur ulang data antara banyak disk, meningkatkan

kinerja atau menyimpan arsip pada secondary storage.

5. People

Komponen terakhir adalah manusia yang terlibat dengan sistem. Ada empat tipe role

atau peran yang terlibat dalam sebuah DBMS:

1. Data dan database aministrators

a. Data Administrators (DA) bertanggung

jawab dalam

mengatur sumber data,

meliputi perencanaan basis data, standa pengaturan dan pengembangan,

kebijakan dan prosedur maupun rancangan konseptual dan logikal basis data.

b. Database Administrators (DBA) bertanggung jawab dalam realisasi fisik basis

data meliputi rancangan physical basis data dan implementasi, keamanan, dan

pengaturan

integritas,

menjaga

sistem operasional

dan

memastikan

kinerja

aplikasi untuk kepuasan pengguna.

2. Database Designers

a. Logical

Database

Designer

berhubungan

dengan

identifikasi

data

(entitas

dan atribut), hubungan antara data, dan batasan pada data untuk disimpan di

basis data.

Physical Database Designer memutuskan bagaimana rancangan basis data

logikal dapat direalisasikan.

Application Developers

bertanggung

jawab

untuk

mengimplementasikan

program aplikasi yang menyediakan syarat-syarat fungsionalitas untuk pengguna

akhir (end-user).

End Users

adalah

klien

untuk

basis

data yang telah dirancang kemudian

diimplementasikan dan dijaga untuk menyediakan kebutuhan mereka

2.3.2 Keuntungan DBMS

Menurut Connolly dan Begg (2010, p77-80), keuntungan DBMS:

1. Kontrol terhadap redudansi data

Pendekatan

basis data

berupaya untuk menghilangkan redudansi dengan

mengintegrasikan file-file supaya salinan dari data yang sama tidak disimpan. Suatu

data mengalami redudansi.

2. Konsistensi data

Dengan menghilangkan atau mengontrol redudansi, akan mengurangi resiko

ketidakkonsistensi-an data. Jika data disimpan lebih dari sekali dan sistem

mengetahuinya

maka

sistem harus

menyakinkan

bahwa

semua

salinan

data

tetap

konsisten.

3. Informasi lebih dari jumlah data yang sama

Dengan

terintegrasinya

data

operasional, maka

memungkinkan

organisasi

untuk

memperoleh informasi tambahan dari data yang sama.

4. Berbagi data

Basis data yang dimiliki oleh keseluruhan organisasi dapat digunakan bersama oleh

pengguna yang berwenang.

5. Meningkatkan integritas data

Integritas basis data menunjukan pada validitas dan konsistensi data yang tersimpan.

6. Meningkatkan Keamanan

Keamanan basis

data

merupakan perlinungan basis data dari

pengguna yang tiak

berwenang. Hal ini dapat ilakukan dengan membentuk username dan password

untuk mengidentifikasikan pengguna yang berwenang menggunakan basis data. Hak

ases yang diberikan pada pengguna yang berwenang pada suatu data dapat dibatasi

oleh jenis operasi (retrieval, insert, update delete)

7. Penegakan standar-standar

Integrasi

membuat

DBA

dapat

mendefinisikan

dan DBMS

untuk

menegakan

standar-standar,

seperti

format

data

untuk fasilitas pertukaran

data antara

system,

konvensi penamaan, standar dokumentasi, prosedur update, dan aturan akses.

8. Skala Ekonomi

Dengam

mengkombinasikan

data

operasional

organisasi

kedalam basis

data

membuat sebuath set aplikasi yang bekerja pada sumber data ini maka bias

menghemat pengeluaran.

9. Menyeimbangkan keperluan yang bertentangan

Setian pengguna pada department memiliki kebutuhan yang mungkin bertentangan

dengan pengguna lainya. Karena basis data dibawah kontrol DBA, maka DBA bisa

membuat

keputusan

mengenai

desain

dan kegiatan

operasional

basis

data

yang

menyediakan sumber daya yang terbaik bagi organisasi.

10. Mengingkatkan aksesbilitas data dan responsive data

Sebagai

hasil

dari

integrasi,

data

yang melewati

batasan

antar

department

dapat

diakses oleh pengguna akhir.

11. Meningkatkan Produktivitas

DBMS

menyediakan

banyak

fungsi standar

sehingga

memungkinkan programmer

berkonsentrasi pada fungsionalitas spesifik yang dibutuhkan oleh pengguna tanpa

harus memikirkan tetang rincian implementasi level bawah. Hal ini menghasilkan

pengingkatan produktivitas programmer dan mengurangi waktu pengembangan.

12. Meningkatkan perawatan melalui data independence

DBMS

memisahkan

eskripsi

data

dari

aplikasi

sehingga

membuat

aplikasi

tidak

dapat terpegaruh pada perubahan deskripsi data.

13. Meningkatkan konkurensi

Memunginkan

pengguna

alam mengakses

data

yang

sama

secara

simultan

tanpa

menganggu satu sama lain.

14. Meningkatkan pelayanan backup dan recovery

Untuk melindungi data dari kegagalan sistem computer atau program aplikasi maka

dilakukan

backup

terhadap

data

secara teratur. Apabila setelah dilakukan backup

terjadi

kegagalan,

DBMS

menyediakan

fasilitas untuk meminimalkan

jumlah

pemrosesan yang hilang.

2.3.3 Kerugian DBMS

Menurut Connolly dan Begg (2010, p80-81), kerugian DBMS :

1. Kompleksitas

Ketentuan dari sebuah fungsionalitas yang baik menjadikan DBMS sebuah

perangkat lunak yang sangat kompleks.

2. Ukuran

Luas dan kompleksnya fungsionalitas menjadikan DBMS sebuah perangkat lunak

yang membutuhkan media penyimpanan yang sangat besar dan jumlah memori besar

untuk menjalankan DBMS secara efisien.

3. Meningkatkan biaya untuk tambahan perangkat keras

Keperluan media penyimpanan untuk DBMS dan basis data membutuhkan

pembelian tambahan media penyimpanan.

Meningkatkan biaya untuk DBMS

biaya untuk suatu DBMS bervariasi tergantung pada lingkungan dan fungsionalitas

yang diberikan.

5. Meningkatkan biaya untuk konversi data

Biaya untuk mengubah aplikasi yang telah ada agar dapat berjalan pada DBMS dan

perangkat keras

yang baru. Selain

itu juga meliputi biaya pelatihan pegawai untuk

menggunakan sistem yang baru.

6. Kinerja

DBMS ditulis secara umum

untuk melayani banyak aplikasi dari pada

hanya satu.

Hasilnya

beberapa

aplikasi

mungkin

tidak dapat

berjalan secepat

sebagaimana

mestinya.

7. Dampak kegagalan yang lebih besar

Sentralisasi sumber daya meningkatkan kerentanan system. Karena semua

penggunaan aplikasi bergantung kepada ketersediaan dari DBMS, kegagalan pada

beberapa komponen bisa menyebabkan terhentinya kegiatan operasional.

2.3.4 Fungsi Database Management System

Menurut Connolly dan

Begg (2010, p100-104), menjelaskan

fungsi-fungsi dari

Database Management System, yaitu:

1. Data Storage, Retrieval, dan Update

DBMS harus melengkapi pengguna dengan kemampuan yang menyimpan,

menelusuri, meng-update data dalam basis data.

2. A User-Accessible Catalog

DBMS harus menyediakan sebuah dokumen yang menyimpan deskripsi dari seluruh

data item yang disimpan dan dapat diakses pengguna.

3. Transaction Support

DBMS harus menyediakan suatu mekanisme yang menjamin bahwa semua kegiatan

update maupun tidak, sesuai dengan transaksi yang dilakukan.

4. Concurrency Control Services

DBMS harus menyediakan mekanisme yang menjamin bahwa basis data di-update

dengan benar ketika lebih dari satu pemakai mengakses ataupun meng-update basis

data secara bersamaan.

5. Recovery Services

DBMS harus menyediakan mekanisme untuk memperbaiki basis data yang dapat

rusak karena suatu hal.

6. Authorization services

DBMS harus menyediakan mekanisme bahwa hanya pengguna yang mempunyai hak

yang dapat mengakses basis data.

7. Support for Communication Data

DBMS harus dapat berintegrasi dengan perangkat lunak komunikasi.

8. Integrity Services

DBMS harus dapat menyediakan cara untuk menjamin bahwa data dalam basis data

dan perubahan pada data mengikuti aturan yang telah ditetapkan sebelumnya.

9. Services to Promote Data Independence

DBMS

harus

mencakup

fasilitas

yang mendukung

indipendensi dari program yang

struktur basis data.

10. Utility Services

DBMS

harus

menyediakan

satu set

fasilitas

pelayanan.

Contoh dari

pelayanannya

adalah :

1. Fasilitas import database dari flat files, dan fasilitas export flat files ke database.

Fasilitas monitoring, untuk

memantau penggunaan database dan setiap operasi

yang dilakukan.

3. Statistical

Analysis

Programs,

untuk

memeriksa

performa

dan

statistik

penggunaan.

4. Koleksi tempat pembuangan dan relokasi,

untuk

memindahkan dan

menghapus

records secara fisik dari tempat penyimpanan, dan

mengkonsolidasikan ruang

yang kosong, dan merelokasikan pada saat dibutuhkan.

2.3.5 Arsitektur Multi-User DBMS

Menurut

Connolly

dan

Begg

(2010,

p108-115), terdapat 3

arsitektur

yang biasa

digunakan untuk mengimplementasikan multi-user DBMS yakni :

1. Teleprocessing

Arsitektur

tradisional

untuk

sistem multi-user

adalah

teleprocessing,

yang

dimana

satu komputer dengan single CPU dan sejumlah terminal.

Gambar 2.2 Teleporcessing Topology

(Sumber: Connolly Dan Begg, 2010, p108)

2. Arsitektur File-Server

Sebuah komputer dihubungkan pada suatu jaringan dengan tujuan utama untuk

menyediakan penyimpanan

yang dapat

membagi file

seperti dokumen, spreadsheet,

gambar, dan database.

Gambar 2.3 arsitektur File-Server

(Sumber: Connolly Dan Begg, 2010, p109)

3. Arsitektur Client-Server

Client server

mengacu

kepada

cara komponen

software

berinteraksi

kepada

form

dari

sistem.

Terdapat

proses

client

yang

memerlukan

sumber, dan

sebuah

server

yang menyediakan sumber tersebut.

Gambar 2.4 arsitektur Client-Server

(Sumber: Connolly Dan Begg, 2010, p110)

2.4 Fact-Finding Techniques

Menurut Connolly dan Begg (2010, p341-345), proses formal mengunakan

teknik seperti interview dan

kuisioner

untuk

mengumpulkan

fakta

mengenai

istem,

kebutuhan, dan preferensi. Seorang database developer biasanya menggunakan

beberapa fact-finding techniques selama mengerjakan proyek database.

Dari pengertian di atas dapat disimpulkan bahwa

teknik fact finding seperti

interview dan

kuesioner

digunakan

untuk

mengetahui

data-data

mengenai

kebutuhan

sistem pada suatu perusahaan.

Terdapat 5 teknik fact-finding yang biasanya digunakan

yaitu:

1. Examining Documentation

Dengan memeriksa dokumentasi dari sistem yang ada seperti, form, laporan, dan file

maka akan dapat memahami sistem berjalan dengan cepat.

2. Interviewing

Interviewing merupakan

teknik

wawancara

untuk

mendapatkan

informasi

dari

individual secara tatap muka. Terdapat 2 bentuk wawancara yang dapat dilakukan

yang

pertama

adalah

unstructured

interview sehingga

focus

wawancara

dapat

berpindah-pindah.

Bentuk

kedua

adalah structured

interview

dimana

interviewer

memiliki pertanyaan-pertanyaan spesifik untuk dijawab oleh interviewee. Pertanyaan

tersebut dapat berupa open-ended questions dan closed ended-questions.

3. Observing the enterprise in operation

Dengan teknik ini maka dimungkinkan partisipasi atau pengamatan perorangan pada

saat melakukan aktivitas dan belajar mengenai sistem yang sedang berjalan.

4. Research

Teknik

fact-finding

yang

berguna

untuk

penelitian aplikasi

dan

permasalahan.

Computer trade journal, buku reference, dan internet adalah sumber informasi yang

bagus. Karena menyediakan infromasi bagaimana orang lain menyelesaikan masalah

dengan kemiripan permasalahan.

5. Questionnaires

Kuesioner adalah

fasilitas untuk

mendapatkan fakta dari banyak perserta sekaligus.

Terdapat dua bentuk pertanyaan pada suatu kuesioner,

free-format question dan

fixed-format question.

Free

format

question

mengedepankan

kebebasan responden

dalam menjawab pertanyaan sehingga pertanyaan tidak disertai oleh jawaban yang

sudah diarahkan sebelumnya. Fixed-format question menginginkan jawaban dengan

memiliki jawaban yang paling sesuai dari beberapa jawaban yang ada.

2.5 Data Model

Menurut Connolly dan Begg (2010, p95), data model merupakan kumpulan konsep

yang terintegrasi untuk mendeskripsikan dan memanipulasi data, hubungan antara data,

dan Constraints terhadap data dalam suatu organisasi.

Menurut

Hoberman

(2009,

p86),

data

model

merupakan

alat wayfinding

untuk

menjalankan

sebuah bisnis

dan

profesional

TI,

yang

menggunakan

sebuah

set

simbol

dan

teks

untuk

menjelaskan subset

dari

informasi

yang

nyata

untuk

meningkatkan

komunikasi data dalam organisasi dan

menghasilkan aplikasi

yang

fleksibel dan stabil.

Menurut definisi

atas

dapat

diartikan

bahwa data

model

adalah kumpulan

konsep

untuk

menjelaskan,

memanipulasi, menentukan hubungan, dan menentukan

Constraints pada data dalam suatu organisasi dan

menghasilkan aplikasi

yang

fleksibel

dan stabil. Contoh dari data model adalah class diagram dan ERD.

2.6 Struktur Data Relational

Menurut

Connolly

dan

Begg

(2010,

p144-146),

struktur data

relational

terbagi

menjadi beberapa bagian yaitu :

1. Relasi : merupakan sebuah table dengan baris dan kolom.

2. Atribut : merupakan nama kolom dari relasi.

3. Domain : merupakan sekelompok nilai yang diijinkan bagi satu atau lebih attributes.

4. Tuple : Merupakan baris dari sebuah relasi.

Degree: merupakan jumlah atribut yang terdapat dalam relasi

6. Cardinality : merupakan jumlah tuple yang terdapat dalam relasi.

7. Database Relational : merupakan kumpulan dari relasi skema yang ternormalisasi.

2.7 Relational Keys

Menurut Connolly dan Begg (2010 p150-151), Relational key dibagi menjadi

beberapa jenis yaitu:

1. Superkey : Merupakan sebuah atribut atau sekelompok atribut yang mengidentifikasi

secara untuk tuple dalam relasi.

2. Candidate key: Merupakan Superkey dalam relasi. Candidate Key (K), bagi sebuah

relasi (R) mempunyai dua properti yaitu:

a. Keunikan

dalam setiap tuple dari R,

nilai dari K secara unik

mengidentifikasi

tuple tersebut.

b. Irreducibility

tidak ada subset

yang sesuai dari K

yang

mempunyai keunikan

sifat, ketika sebuah key terdiri dari

lebih dari satu atribut kita sebut

ini sebagai

composite key.

3. Primary Key :

merupakan candidate key yang terpilih untuk mengidentifikasi tuple

secara unik dalam satu relasi. Sementara candidate key yang tidak

terpilih

sebagai

primary key disebut sebagai alternate key.

4. Foreign Key : merupakan sebuah atribut atau sekelompok atribut dalam relasi yang

dibandingkan dengan candidate key pada beberapa relasi.

Gambar 2.5 Contoh hubungan cabang dengan staff

(Sumber: Connolly dan Begg, 2010, p145)

2.8 View

Menurut Connoly dan

Begg (2010, p155), view adalah

hasil dinamis dari

satu atau

lebih operasi tabel pada tabel dasar untuk

menghasilkan tabel baru. View adalah relasi

virtual yang

tidak

semestinya ada di dalam database tetapi dihasilkan dari permintaan

tertentu oleh pengguna pada saat tertentu.

Menurut Frost (2006, p25-26), mendefinisikan view adalah subset tabel turunan dari

tabel dasar, view

memungkinkan database administrator

untuk

membatasi bagian dari

database yang terlihat untuk tiap user.

Dari

definisi

atas

dapat

disimpulkan

bahwa view dibuat

oleh

database

administrator dari beberapa tabel inti yang beberapa dari atribut tabel tersebut terbentuk

suatu tabel virtual baru yang disesuaikan dengan tiap-tiap pemakai akhir.

2.9 Arsitektur ANSI-SPARC Three Level

Menurut

Connolly

dan

Begg

(2010,

p87-90),

arsitektur

ANSI-SPARC three-level

terdiri

dari

external, conceptual,

dan

internal

level. Arsitektur

ini

menyediakan

dasar

untuk memahami fungsionalitas dari DBMS. Tujuan dari three-level architecture adalah

untuk memisahkan tiap

view database pengguna dengan cara representasi fisik dari

database tersebut.

Menurut definisi di atas dapat diartikan bahwa arsitektur ANSI-SPARC three-level

adalah arsitektur yang menggambarkan cara pengguna melihat data pada sistem operasi

melihat

data,

dan

dimana

data

sebenarnya disimpan

menggunakan

struktur

data

dan

pengaturan file.

1. Level External

Level

external

merupakan

cara

pandang

pengguna

dari

database.

Level

ini

mendeskripsikan bagian dari database yang bersangkutan dengan setiap pengguna.

2. Level Conceptual

Merupakan himpunan dari view di dalam database. Level ini mendeskripsikan data

apa yang disimpan di dalam database dan hubungan antar data.

3. Level Internal

Merupakan representasi fisik dari database di dalam komputer. Level ini

mendeskripsikan bagaimana data disimpan di dalam database.

Gambar 2.6 ANSI-SPARC Three-level Architecture.

(Sumber: Connolly Dan Begg, 2010, p87)

2.10 Integrity Constraint

Menurut Connolly

dan

Begg

(2010, p153-154) integrity constraint adalah bagian

dari data model yang memastikan ketepatan data.

Menurut definisi di atas dapat diartikan bahwa integrity constraint adalah aturan-

aturan yang harus dijalani demi menjaga ketepatan, dan kelengkapan data.

Intergrity Constraint terbagi menjadi beberapa jenis yaitu :

1. Null

Merupakan

gambaran

sebuah

nilai

bagi

sebuah

atribut

yang tidak

diketahui atau

tidak digunakan bagi tuple tersebut. Null

tidak sama dengan numeric 0 atau spasi,

tetapi null menggambarkan ketidakadaan nilai.

2. Entity Integrity

Pada

relasi

dasar, tidak ada

atribut

primary

key

yang

bernilai null. Berdasarkan

definisi

atas,

primary key minimal berperan

sebagai indentifier

yang digunakan

untuk mengidentifikasikan tuple secara unik.

3. Referential Integrity

Jika

terdapat

foreign key

dalam

relasi,

maka

nilai

foreign

key

tersebut

akan

dibandingkan dengan nilai candidate key dari beberapa tuple pada relasi itu sendiri

atau nilai foreign key harus semuanya null.

Menurut Connolly dan Begg(2010, p504), ada beberapa strategi yang digunakan

yaitu:

a. NO ACTION: mencegah penghapusan dari relasi induk jika terdapat referensi ke

tuple anak.

b. CASCADE:

jika

tuple

induk

dihapus

maka

secara

otomatis

tuple

anak

akan

dihapus.

c. SET NULL: jika tuple induk dihapus,

maka foreign key pada semua tuple

anak

akan diberikan nilai NULL.

d. SET DEFAULT: jika tuple induk dihapus,

maka foreign key pada semua tuple

anak akan diberikan nilai default.

e. NO

CHECK:

jika

tuple

induk

dihapus,

maka

akan

dilakukan

apapun

untuk

menyakinkan bahwa referential integrity terjaga.

4. General Constraint

Peraturan tambahan yang ditentukan oleh pengguna atau database administrator dari

database,

yang

mendefinisikan constraint

beberapa

aspek

dari

sudut

pandang

perusahaaan.

2.11 Entity-Relationship Model (ERM)

Menurut Connolly dan

Begg

(2010, p371), E-R model

adalah pendekatan Top-

down,

perancangan

basis

data

yang

dimulai dengan

mengidentifikasikan

data

penting

yang disebut entities dan relationships diantara data yang harus diwujudkan dalam suatu

model.

Menurut Silberschatz, Korth, dan Sudarshan (2006, p8), Entity relationship data

model merupakan model yang berdasarkan persepsi dari dunia nyata yang mengandung

kumpulan object yang disebut dengan entitas dan relasi antara entitas tersebut.

Menurut definisi

di atas dapat diartikan bahwa

E-R

model

adalah pendekatan

top-down

perancangan

basis

data

yang

terdiri

dari

entitas

dan

hubungan

antar

entitas

yang ditentukan berdasarkan fakta-fakta pada dunia nyata.

2.11.1 Entity Types

Menurut Connolly dan Begg (2010, p372), entity type adalah sekumpulan objek

yang diidentifikasikan oleh sebuah perusahaan atau perorangan yang mempunyai sifat –

sifat

yang sama dan mempunyai keberadaan yang independen. Sebuah entity memiliki

keberadaannya yang bebas dan bisa menjadi objek dengan fisik (atau real) atau menjadi

objek dengan keberadaan konseptual (atau abstrak). Artinya perancang yang berbeda

mungkin mengidentifikasikan entity yang berbeda pula.

Menurut definisi di atas dapat diartikan entity type adalah objek-objek fisik atau

abstrak yang memiliki property yang sama dan bersifat independen.

EntityName

Staff

Branch

Gambar 2.7 Contoh tipe entity

(Sumber: Connolly dan Begg, 2010, p374)

Menurut Connolly

dan

Begg

(2010, p373-374), entity occurrence adalah objek

unik yang dapat diidentifikasikan dari sebuah tipe entity.

Menurut definisi di atas dapat diartikan entity occurrence adalah kejadian unik

yang terdapat pada suatu entitas.

2.11.2 Relationship Types

Menurut

Connolly

dan

Begg

(2010,

p374),

sebuah

relationship

type adalah

sekumpulan asosiasi antara satu atau lebih tipe entity yang ikut serta. Setiap relation type

diberi nama sesuai dengan fungsinya.

Menurut definisi di atas dapat diartikan relasionship type adalah sekumpulkan

hubungan antara satu atau lebih entitas dengan entitas lainnya yang diberi nama sesuai

dengan kejadian antara entitas.

Menurut

Connolly

dan

Begg

(2010,

p375),

relationship occurrence adalah

hubungan yang dapat diidentifikasi secara unik, yang termasuk satu kejadian dari setiap

entity yang berpartisipasi.

Menurut

definisi

atas

dapat

diartikan relationship

occurrence

merupakan

kejadian unik yang menghubungkan antara satu entitas dengan entitas lainnya.

Gambar 2.8 Semantic net yang menujukan occurrences dari tipe

hubunganHas.

(Sumber: Connolly dan Begg, 2010, p375)

Gambar 2.9 Diagram

yang menunjukan entitas Branch memiliki tipe

hubungan Has dengan Staff.

(Sumber: Connolly dan Begg, 2010, p376)

Menurut Connolly dan Begg (2010, p376), dalam relation types terdapat degree

of relation type yang merupakan sejumlah tipe entity yang ikut serta dalam relationship.

Entity yang terkait dalam sebuah fakta relation type diunjuk sebagai participants dalam

relationship.

Jumlah participants dalam relationship type disebut degree (derajat) dari

relationship tersebut.

Menurut definisi di atas dapat diartikan relation type adalah jumlah tipe entitas

yang terlibat dalam suatu relationship.

Derajat relationship terdiri dari :

1. Binary relationship, keterhubungan antar dua tipe entity

PrivateOwner

POwns

PropertyForRen

Gambar 2.10 Contoh Binary Relationship.

(Sumber: Connolly dan Begg, 2010, p376)

2. Ternary relationship, keterhubungan antar tiga tipe entity. Contoh Ternary

relationship

yang

diberi

nama

Hubungan

ini

melibatkan

tiga

tipe

entity

yaitu

Staff, Branch,

dan

Relationship

ini

menggambarkan

tentang Staff

yang

mendaftarkan Client pada Branch

Staff

Registers

Branch

Client

Gambar 2.11 Contoh Ternary Relationship.

(Sumber: Connolly dan Begg, 2010, p377)

Quternary relationship,

keterhubungan

antar

empat

entity.

Contoh

Quternary

relationship yang

diberi

nama

Arranges.

Relasi

ini

melibatkan

empat entity yaitu

Buyer,

Solicitor, Financial Institution

dan

Bid.

Relasi

ini

menggambarkan

Buyer

diberi masukkan oleh Solicitor, dan didukung oleh Financial Institution melakukan

penawaran (Bid).

Solicitor

Buyer

Arrange

Financial

Instotution

Client

Gambar 2.12 Contoh Quternary Relationship

(Sumber: Connolly dan Begg, 2010, p377)

4. Recursive relationship

merupakan

keterbukaan

antar

satu tipe entity,

dimana

tipe

entity tersebut berpartisipasi lebih dari

satu kali dengan peran yang berbeda.

Relationship dapat diberikan role names untuk mengidentifikasikan keterkaitan tipe

identifikasi dalam relationship.

Role Name

Supervises

Supervisor

Role

Supervise

Staff

Gambar 2.13 Contoh Recursive Relationship

(Sumber: Connolly dan Begg, 2010, p378)

2.11.3 Attributes dan domain

Menurut Connolly dan Begg (2010, p379), atribut adalah sebuah

properti atau

sifat dari entity dan relationship.

Menurut Connolly dan Begg (2010. p379),

domain atribut adalah

sekelompok

nilai yang diperbolehkan bagi satu atau lebih atribut.

Dari definisi-definisi diatas dapat disimpulkan bahwa atribut merupakan bagian

dari suatu entitas dan domain adalah bagian lebih dari satu atribut.

2.11.4 Simple dan Composite Attribute

Menurut

Connolly

dan

Begg

(2010,

p379-380),

atribut

simple

adalah sebuah

atribut yang terdiri dari komponen tunggal dengan keberadaannya yang bebas.

Sedangkan atribut composite menurut Connolly dan Begg (2010, p351), adalah

sebuah atribut yang terdiri dari berbagai komponen, setiap atribut dengan keberadaannya

yang bebas.

Dari definisi-definisi diatas dapat disimpulkan bahwa simple atribut

merupakan

atribut yang tidak terdiri dari beberapa atribut lainnya, sedang kan composite merupakan

atribut yang terdiri dari gabungan beberapa atribut.

2.11.5 Attribute Single-Valued dan Multi-Valued

Menurut Connolly

dan

Begg

(2010, p380),

atribut

single-value

adalah

atribut

yang berisi nilai tunggal bagi setiap kejadian dari setiap entity.

Sedangkan Menurut Connolly dan Begg (2005, p352), atribut multi-valued

adalah atribut yang berisi sebagai nilai bagi setiap kejadian dari setiap entity.

Dari definisi di atas dapat disimpulkan atribut

single-value

adalah atribut

yang

nilainya terdiri dari satu nilai saja, sedangkan multi-valued adalah nilai atribut yang lebih

dari satu dalam tuple yang sama.

2.11.6 Derived Attribute

Menurut Connolly

dan

Begg (2010, p380-381),

atribut

derived

adalah

atribut

yang menggambarkan sebuah nilai yang dapat diperoleh dari nilai atribut yang

berhubungan atau sekelompok atribut, tidak perlu dalam entity yang sama.

Menurut definisi di atas dapat diartikan bahwa derived attribut merupakan

atribut

yang

diperoleh

dari

nilai atribut atau

beberapa

atribut

dalam atau

tidak

dalam

entitas yang sama.

2.11.7 Keys

Menurut Connolly

dan

Begg

(2010,

p381),

Candidate key

adalah

set

minimal

dari atribut yang secara unik mengidentifikasikan tiap occurence dari tipe entitas.

Menurut Connolly dan Begg (2010, p381), primary key adalah candidate

key yang terpilih secara untuk untuk mengientifikasikan occurrence dari tipe entitas.

Menurut Connolly dan

Begg (2010, p382), composite key adalah

sebuah

candidate key yang memiliki dua atau lebih atribut.

Dari

definisi-definisi

diatas dapat

disimpulkan candidate key adalah

key

yang

dapat mengidentifikasikan setiap record secara

unik dan primary key adalah candidate

key yang

terpilih

untuk record secara

unik pada suatu entitas, semetara composite key

adalah sebuah atribut pada entitas yang memiliki 2 atau lebih atribut.

Gambar 2.14 Diagram yang

merepresentasikan entitas Staff dan Branch dengan

atributnya

(Sumber: Connolly dan Begg, 2010, p382)

2.11.8 Strong Entity

Menurut

Connolly

dan

Begg

(2010,

p383),

entity

kuat

adalah entity

yang

keberadaannya tidak bergantung pada beberapa entity yang lain. Karakter dari entity ini

adalah

bahwa

setiap

kejadian

entity

teridentifikasi

secara unik

menggunakan

atribut

primary key.

Menurut definisi di atas dapat diartikan bahwa entitas kuat adalah entitas

yang

memiliki primary key sendiri serta tidak bergantung kepada primary key entitas lainnya.

2.11.9 Weak Entity

Menurut Connolly dan Begg (2010, p383),

entity lemah adalah entity yang

keberadaannya tergantung pada beberapa entity yang lain.

Menurut definisi di atas dapat diartikan bahwa entitas lemah adalah entitas yang

keberadaannya bergantung kepada entitas lainya.

Strong Entity

Weak Entity

Client

States >

Preference

ClientNo{PK}

Name

fName

lName

telNo

PrefType

maxRent

Gambar 2.15 Strong Entity Type Client dan Weak Entity Type Preference

(Sumber: Connolly dan Begg, 2010, p384)

2.11.10 Multiplicity

Menurut Connolly dan begg (2010, p385), multiplicity adalah angka (atau jarak)

dari kemungkinan

occurrence

pada sebuah tipe entitas yang

mungkin menghubungkan

ke sebuah occurence hubungan tipe entitas melalui hubungan tertentu.

Menurut

definisi

atas dapat

diartikan multiplicity adalah jumlah

range dari

kejadian yang terjadi antara satu entitas dengan entitas

lainnya yang

terhubung melalui

suatu relationship.

Terdapat 3 jenis tipe hubungan menggunakan integrity constraint yaitu:

1. One-to-One (1:1) Relationships

Gambar

2.16 Semantic

Net

yang

menunjukan

kejadian

tipe

relasi

Staff

Manages Branch.

(Sumber : Connolly dan Begg, 2010, p386)

2. One-to Many (1:*) Relationships

Gambar

2.17 Semantic

Net

yang

menunjukan

kejadian

tipe

relasi

Staff

PropertyForRent.

(Sumber : Connolly dan Begg, 2010, p387)

3. Many-to-Many (*:*) Relationships

Gambar

2.18 Semantic

Net

yang

menunjukan 2

kejadian

tipe

relasi Newspaper

PropertyForRent.

(Sumber : Connolly dan Begg, 2010, p387)

2.12 Structre Query Language(SQL)

Menurut Post (2005, p145)

SQL

adalah

bahasa query standard yang dibuat

melalui ISO

(international organization of standards)

dan

di-update setiap beberapa

tahun.

Menurut

Hoffer,

Prescot

dan

topi

(2009,

p349)

SQL

adalah

facto

bahasa

standard untuk membuat dan meng-queri database relasional.

Dari

definisi-definisi

atas dapat

disimpulkan,

SQL

adalah

bahasa

query

database

terstandar

yang

digunakan

untuk

membuat

dan

meng-queri

database

relasional yang melalui ISO (international organization of standards).

2.13 Database Language

Menurut

Connolly

dan

Begg

(2010,

p91), data

sublanguage

terdiri

dari

dua

bagian yaitu Data Definition Language (DDL) dan Data Manipulation Language

(DML).

DDL digunakan untuk menentukan skema database dan DML digunakan baik

untuk membaca dan meng-update database. Keduanya disebut data sublanguage karena

mereka

tidak

membangun

semua

kebutuhan

pemrograman

seperti

pernyataan

kondisi

dan iterative yang digunakan oleh beberapa bahasa pemrograman tingkat tinggi lainya.

Menurut definisi di

atas dapat

diartikan

DDL

dan

DML

merupakan

data

sublanguage karena tidak mampu membangun semua kebutuhan pemrograman.

2.13.1 Data Definition Language (DDL)

Menurut Ramakrishnan dan Gehrke (2010, p131), DDL adalah subset dari SQL

yang mendukung, pembuatan, penghapusan, dan modifikasi dari definisi tabel dan

views.

Menurut Connolly dan Begg (2010, p92), DDL adalah suatu bahasa yang

mengijinkan DBA atau pengguna untuk mendeskripsikan dan memberi nama entitas,

atribut

dan

relationship

yang diperlukan

untuk aplikasi,

bersama dengan semua

integritas yang berhubungan dan security constraints.

Dari definisi-definisi diatas dapat disimpulkan, DDL adalah bahasa basis data

yang digunakan untuk mendefinisikan, suatu entitas, atribut, dan hubungannya.

Beberapa statement DDL:

1. CREATE TABLE

Untuk membuat table dengan mengidentifikasikan tipe data untuk tiap kolom.

2. ALTER TABLE

Untuk menambah atau membuang kolom dan constrain.

3. DROP TABLE

Untuk

membuang

atau

menghapus

table beserta

semua

data

yang

terkait di

dalamnya.

4. CREATE INDEX

Untuk membuat index pada suatu table.

5. DROP INDEX

Untuk membuang atau menghapus index yang suah dibuat sebelumnya.

6. CREATE VIEW

Untuk membuat view dari beberapa table.

7. DROP VIEW

Untuk membuang atau menghapus view yang sudah dibuat sebelumnya.

2.13.2 Data Manipulation Language (DML)

Menurut Ramakhrishnan dan Gehrke (2003, p131), DML adalah subset dari SQL

yang

mengijinkan

pengguna

untuk

pose

queries an

untuk

meng

insert,

delete

dan

mengubah baris.

Menurut

Connolly

dan

Begg

(2010,

p92),

DML adalah suatu bahasa yang

menyediakan sekumpulan operasi yang diinginkan untuk mendukung operasi manipulasi

data utama pada data yang diperoleh dalam database.

Menurut definisi di atas

dapat diartikan DML adalah

bahasa basis data yang

menngijinkan pengguna untuk melakukan modifikasi data di dalam database.

DML menyediakan operasi dasar manipulasi data pada data yang ada di dalam database

yaitu:

1. INSERT

Pemasukan data baru ke dalam database (insertion).

2. UPDATE

Mengubah atau memodifikasi data yang disimpan dalam database (modify).

3. SELECT

Memanggilan data yang ada dalam database (retrieve).

4. DELETE

Menghapus data di dalam database (delete).

DML dapat dibedakan menjadi 2 tipe yaitu :

1. Procedural DML suatu bahasa yang mengijinkan pengguna untuk memberitahukan

sistem data apa yang dibutuhkan dan bagaimana cara data tersebut diambil.

2. Non

procedural

DML

suatu bahasa

yang

mengijinkan

pengguna

mengkondisikan

data apa yang dibutuhkan dari pada bagaimana cara data tersebut diambil.

2.13.3 Discretionary Access Control(DAC)

Menurut Connolly dan

Begg (2011, p416), discretionary access control adalah

dimana tiap pengguna diberikan hak akses yang sesuai (atau disebut juga dengan

privilages) pada tiap objek di dalam basis data.

Menurut definisi di atas dapat diartikan DAC adalah perintah yang digunakan

untuk menentukan privilages tingkatan pengguna terhadap tiap objek yang berada pada

basis data.

Beberapa privilages yang ditetapkan oleh standar ISO adalah:

1. SELECT : hak istimewa untuk membaca data dari suatu tabel.

2. INSERT : hak istimewa untuk memasukan baris baru kedalam tabel.

3. UPDATE : hak istemewa untuk mengubah baris dari data di dalam tabel.

4. DELETE : hak istimewa untuk menghapus baris dari data dari suatu tabel.

5. REFERENCES : hak istimewa untuk memberi referensi kolom dari suatu nama tabel

pada batasan integritas.

Structured Query Language hanya mendukung discretionary access control

melalui

statement:

1. GRANT : statement GRANT digunakan untuk memberikan privileges kepada objek

di basis data kepada pengguna yang spesifik.

2. REVOKE

statement REVOKE digunakan untuk memberikan privileges

yang telah

diberikan melalui GRANT statement.

2.14 Normalisasi

Menurut Connolly dan Begg (2011, p416), normalisasi adalah suatu

teknik untuk

menghasilkan sekumpulan relasi dengan properties yang diinginkan, memenuhi

kebutuhan data pada perusahaan.

Menururt Peter dan Coronel

(2005, p176), normalisasi adalah proses menetapkan

atribut untuk entitas. Normalisasi mengurangi redudansi data dan membantu

menghilangkan anomali data yang berasal dari redudansi tersebut.

Menurut definisi

atas

dapat

diartikan

bahwa

normalisasi

adalah proses

untuk

menghasilkan atribut untuk entitas dan relasinya, serta membantu menghilangkan

anomali data yang berasal dari redudansi.

Gambar 2.19 Tahapan Normalisasi.

(Sumber: Connolly dan Begg, 2010, p429)

2.14.1 Unnormalized Form (UNF)

Menurut Connolly dan Begg (2010, p430), Unnormalized Form (UNF)

dapat

diartikan sebagai UNF

yaitu

sebuah table

yang

mengandung satu atau

lebih

repeating

group. Untuk membuat table unnormalized yaitu dengan memindahkan data dari sumber

informasi ke dalam format table dengan baris dan kolom. Jika ada atribut yang bernilai

multivalue, maka relasi tersebut dalam kondisi unnormalized.

Contoh Repeating Groups :

clientNo

cName

propert

yNo

pAddress

rentStart

rentFinish

rent

owner

oName

CR76

John

Kay

PG4

PG16

Lawrence

St, Glasgow

Novar Dr.

Glasgow

1-Jul-00

1-Sep-01

31-Aug-01

1-Sep-02

350

450

CO40

C093

Tina Murphy

Tony Shaw

CR56

Aline

Stewart

PG4

PG36

PG16

Lawrence

St, Glasgow

Manor Rd,

Glasgow

Novar Dr.

Glasgow

1-Sep-99

10-Oct-00

1-Nov-01

10-Jun-00

1-Dec-01

10-Aug-03

350

375

450

CO40

CO93

Tina Murphy

Tony Shaw

Tabel 2.1 Tabel ClientRental Unormalized.

(Sumber: Connolly dan Begg, 2010, p432)

Repeating Group = (properyNo, pAddress, rentStart, rentFinish, rent, ownerNo,

oName)

2.14.2 First Normal Form (1NF)

Menurut

Connolly

dan

Begg

(2010,

p430),

First Normal Form

(1NF)

adalah

sebuah relasi yang mana titik pertemuan antara setiap baris dan kolom yang berisi satu

dan hanya satu nilai.

Cara merubah UNF ke 1NF adalah dengan mengidentifikasi dan memisahkan

repeating groups dari tabel, terdapat dua pendekatan untuk memisahkan repeating

groups dari unormalized tables:

1. Memasukan

data

yang

semestinya

ke dalam

kolom

yang kosong

pada

baris

yang

berisikan data yang berulang (flattening the table).

2. Dengan

menaruh

repeating

data

dengan

meng-copy

kunci

atribut

yang

sesungguhnya ke dalam relasi terpisah.

ClientRental

clientNo

propertyNo

cName

pAddress

rentStart

rentFinish

rent

ownerNo

oName

CR76

PG4

John

Kay

Lawrence

St, Glasgow

1-Jul-00

31-Aug-

350

CO40

Tina

Murphy

CR76

PG16

John

Kay

Novar Dr.

Glasgow

1-Sep-01

1-Sep-02

450

C093

Tony

Shaw

CR56

PG4

Aline

Stewart

Lawrence

St, Glasgow

1-Sep-99

10-Jun-00

350

CO40

Tina

Murphy

CR56

PG36

Aline

Stewart

Manor Rd,

Glasgow

10-Oct-

1-Dec-01

375

CO93

Tony

Shaw

CR56

PG16

Aline

Stewart

Novar Dr.

Glasgow

1-Nov-01

10-Aug-

450

CO93

Tony

Shaw

Tabel 2.2 Tabel ClientRental 1NF.

(Sumber: Connolly dan Begg, 2010, p432)

Client

clientNo

cName

CR76

John Kay

CR56

Aline Stewart

PropertyRentalOwner

clientNo

propertyNo

pAddress

rentStart

rentFinish

rent

ownerNo

oName

CR76

PG4

Lawrence

St, Glasgow

1-Jul-00

31-Aug-

350

CO40

Tina

Murphy

CR76

PG16

Novar Dr.

Glasgow

1-Sep-01

1-Sep-02

450

C093

Tony Shaw

CR56

PG4

Lawrence

St, Glasgow

1-Sep-99

10-Jun-00

350

CO40

Tina

Murphy

CR56

PG36

Manor Rd,

Glasgow

10-Oct-00

1-Dec-01

375

CO93

Tony Shaw

CR56

PG16

Novar Dr.

Glasgow

1-Nov-01

10-Aug-

450

CO93

Tony Shaw

Tabel 2.3 Tabel ClientRental 1NF alternatif.

(Sumber: Connolly dan Begg, 2010, p433)

2.14.3 Second Normal Form (2NF)

Menurut Connolly

dan

Begg

(2010,

p434),

Second

Normal

Form (2NF)

dapat

berarti sebagai sebuah relasi yang terdapat di dalam 1NF dan setiap atribut yang bukan

primary key full functional depedency pada primary key nya.

clientNo

propertyNo

rentStart

rentFinish

CR76

PG4

1-Jul-00

31-Aug-01

CR76

PG16

1-Sep-01

1-Sep-02

CR56

PG4

1-Sep-99

10-Jun-00

CR56

PG36

10-Oct-00

1-Dec-01

CR56

PG16

1-Nov-01

10-Aug-03

Cara merubah 1NF ke 2NF adalah dengan menghilangkan partial dependency,

Jika terdapat partial dependencies

maka

hapus dengan

menempatkannya

dalam relasi

yang baru bersama dengan saliran determinannya.

Functional dependency menjelaskan

hubungan antara atribut dalam suatu relasi.

Sebagai

contoh,

jka

dan

adalah

atribut dari

relasi

functionally dependent

kepada A (menunjukan A B), jika tiap nilai dari A berhubungan dengan tiap nilai

dari B. (A dan B mungkin mengandung atribut satu atau lebih).

Full Functional

Depedency

adalah suatu keadaan

dimana

jika A

dan

adalah

atribut, B secara fungsional sangat tergantung kepada A dan jika B secara fungsional

bergantung kepada A, tetapi bukan subset dari A. Suatu functional dependency A B

adalah

fully

functional

dependency jika penghilangan

dari

atribut

apapun

dari

akan

menghasilkan hilangnya dependency.

Suatu Full Functional Depedency A

dapat dikatakan partial dependency

jika beberapa atribut dari A dihilangkan dan atribut lainnya masi bertahan.

Client

Rental

clientNo

cName

CR76

John Kay

CR56

Aline Stewart

PropertyOwner

propertyNo

pAddress

rent

ownerNo

oName

PG4

6 Lawrence St, Glasgow

350

CO40

Tina Murphy

PG16

5 Novar Dr. Glasgow

450

C093

Tony Shaw

PG4

6 Lawrence St, Glasgow

350

CO40

Tina Murphy

PG36

2 Manor Rd, Glasgow

375

CO93

Tony Shaw

PG16

5 Novar Dr. Glasgow

450

CO93

Tony Shaw

Tabel 2.4 Tabel ClientRental 2NF alternatif.

(Sumber: Connolly dan Begg, 2010, p435)

clientNo

propertyNo

rentStart

rentFinish

CR76

PG4

1-Jul-00

31-Aug-01

CR76

PG16

1-Sep-01

1-Sep-02

CR56

PG4

1-Sep-99

10-Jun-00

CR56

PG36

10-Oct-00

1-Dec-01

CR56

PG16

1-Nov-01

10-Aug-03

ownerNo

oName

CO40

Tina Murphy

C093

Tony Shaw

CO40

Tina Murphy

CO93

Tony Shaw

CO93

Tony Shaw

2.14.4 Third Normal Form (3NF)

Menurut Connolly dan Begg (2010, p435), Third Normal Form (3NF)

yaitu

sebuah relasi yang terdapat pada bentuk normalisasi pertama dan kedua, yang mana

atribut non primary key bergantung pada primary key nya.

Cara merubah 2NF ke 3NF adalah :

• Jika terdapat transitive dependency maka,

maka transitive dependency harus dipisah

dari tabel dengan menempati atribut pada tabel baru dengan copy dari determinannya.

Transitive dependency adalah suatu kondisi diimana A, B, dan C adalah atribut

dari relasi dimana A B dan B

C, maka C adalah transitive dependency pada A

melalui B.

Client

Rental

clientNo

cName

CR76

John Kay

CR56

Aline Stewart

PropertyForRent

Owner

propertyNo

pAddress

rent

ownerNo

oName

PG4

Lawrence

St, Glasgow

350

CO40

Tina Murphy

PG16

Novar Dr.

Glasgow

450

C093

Tony Shaw

PG4

Lawrence

St, Glasgow

350

CO40

Tina Murphy

PG36

Manor Rd,

Glasgow

375

CO93

Tony Shaw

PG16

Novar Dr.

Glasgow

450

CO93

Tony Shaw

Tabel 2.5 Tabel ClientRental 3NF.

(Sumber: Connolly dan Begg, 2010, 438)

2.15 Database System Development Lifecycle

Menurut

Connolly

dan

Begg

(2010,

p313),

sistem basis data

merupakan

suatu

komponen dasar dari organisasi dengan sistem informasi yang besar.

Hal ini sangat penting untuk diperhatikan karena tahap dari siklus hidup aplikasi

basis data tidaklah harus benar – benar sekuensial. Tetapi meliputi suatu perulangan dari

tahap-tahap

yang

sebelumnya

melalui

umpan balik. Untuk aplikasi basis data kecil

dengan jumlah pengguna yang sedikit, siklus hidup tidak terlalu kompleks.

Bagaimanapun juga, saat merancang sistem basis data yang medium atau pun yang besar

dengan jumlah pengguna antara puluhan sampai dengan ribuan, dengan menggunakan

ratusan queries dan program aplikasi, siklus hidup akan menjadi kompleks.

Menurut

definisi di

atas dapat

diartikan

siklus

hidup

basis data adalah

merupakan tahap yang dilakukan untuk mengembangkan sistem basis data

Gambar 2.20 Siklus Hidup Aplikasi Basis Data

(Sumber: Connolly dan Begg, 2010, p314)

2.15.1 Database Planning

Menurut Connolly dan Begg (2010, p313), perencanaan basis data merupakan

aktifitas

manajemen

yang

memperbolehkan

tahap-tahap

perencanaan

dalam lifecycle

dapat direalisasikan seefektif dan seefisien mungkin.

Dari pengertian diatas dapat

disimpulkan bahwa perencanan basis data

adalah

merupakan pencarian tujuan dan tugas-tugas apa saja yang akan dilakukan oleh sistem

basis data yang akan dirancang.

Perencanaan basis data

harus terintegrasi dengan keseluruhan strategi

sistem informasi

dari organisasi.

Terdapat 3

hal pokok

yang berkaitan dengan strategi

sistem informasi,

yaitu :

• Identifikasi

rencana

dan

sasaran

(goals) dari

enterprise

termasuk

mengenai

sistem

informasi yang dibutuhkan.

• Evaluasi sistem informasi yang ada untuk menetapkan kelebihan dan kekurang yang

dimiliki.

• Penaksiran kesempatan IT yang mungkin memberikan keuntungan kompetitif.

Metodologi untuk mengatasi hal tersebut diatas yaitu :

• Database Planning – Mission Statement :

Mission statement untuk database project mendefinisikan tujuan utama dari aplikasi

database.

Mengarahkan

database project,

biasanya

mendefinisikan

perintah

tugas

(mission statement).

• Database Planning – Mission Objectives :

Ketika mission statement telah didefinisikan, maka mission objectives didefinisikan.

Setiap

objective

(tujuan)

harus

mengidentifikasikan

tugas

khusus

yang

harus

didukung oleh database.

2.15.2

System Definition

Menurut Connolly dan Begg (2010, p316), System Definition adalah menjelaskan

cakupan dan batasan – batasan dari aplikasi basis data dan sudut pandang user

atau

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 kompleks juga memungkinkan permintaan – permintaan dipecah ke dalam bagian –

bagian yang lebih simple.

Dari pengertian diatas dapat disimpulkan bahwa system definition adalah tahapan

menentukan

batasan

dari

sistem yang

akan

dirancang

dan

menyelidiki

hubungannya

dengan sistem informasi perusahaan.

2.15.3 Requirement Collection and Analysis

Menurut Connolly dan Begg (2010, p316), 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 pemakai akan sistem yang baru. Banyak teknik yang dapat

digunakan salah satunya Fact-Finding Technique.

Menurut definisi di atas dapat diartikan bahwa Requirement collection analysis

adalah tahapan dimana pencarian dan pengumpulan data untuk dilakukan analisis.

Informasi 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 database yang baru.

Aktifitas penting

lainnya, adalah

menentukan bagaimana

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

merepresentasikan 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 database.

Model – model

yang

merepresentasikan user view tunggal disebut

lokal data

model,

dan

tersusun

atas

diagram –

diagram dan

dokumentasi

yang

secara

formal

menggambarkan kebutuhan dari user view khusus terhadap database.

Kemudian

lokal

data

model

digabungkan

untuk

menghasilkan

global

data

model,

yang merepresentasikan seluruh user view untuk database.

• Kombinasi keduanya (Combination of both Approaches)

2.15.4 Database Design

Connolly dan Begg (2010, p467), perancangan basis data adalah proses

menciptakan

desain

untuk

basis

data

yang

akan

mendukung mission statement

dan

mission objectives untuk kebutuhan sistem basis data.

Menurut

definisi

atas

dapat

diartikan

bahwa

perancangan

basis

data

merupakan suatu proses pembuatan sebuah desain basis data yang akan mendukung

tujuan dan operasi suatu perusahaan.

2.15.4.1 Pendekatan perancangan basis data

•

Bottom – Up

Dimulai dari atribut dasar (yaitu, sifat – sifat entitas dan relationship), dengan

analisis dari penggabungan antar atribut, yang dikelompokan ke dalam suatu relasi

yang merepresentasikan tipe dari entitas dan relationship antar entitas.

•

Top – Down

Diawali dengan perbentukan model data yang berisi beberapa entitas high-level dan

relationship

dan

lalu

memperbaiki top-down

berturut-turut

untuk

mengidentifikasikan entitas lower level, relationship dan atribut lainnya.

•

Inside – Out

Berhubungan dengan pendekatan bottom-up tetapi sedikit berbeda dengan

identifikasi awal entitas utama dan kemudian menyebar ke entitas, relationship, dan

atribut lainnya yang lebih dulu diidentifikasi.

•

Mixed

Menggunakan pendekatan bottom-up dan top-down untuk bagian yang berbeda

sebelum pada akhirnya digabungkan.

2.15.4.2 Data Modeling

Terdapat dua tujuan utama

dari data modeling yaitu

untuk

mendukung

dalam

memahami

arti

dari

data

(semantics)

dan

untuk

menfasilitasi

komunikasi akan

kebutuhan

informasi yang dibutuhkan. Membangun data model membutuhkan jawaban

dari pertanyaan mengenai entitas, relasi, dan attribute. Dengan melakukannya perancang

dapat

menemukan semantics dari data perusahaan. Suatu data model

dapat

mempermudah memahami

arti dari data dan juga dapat memastikan bahwa sudah

memahami :

•

Tiap perspektif pengguna terhadap data.

•

Asal dari data tersebut, apakah independen dari representasi fisikal.

•

Kegunaan data pada seluruh view pengguna.

2.15.4.3 Fase perancangan basis data

2.15.4.3.1 Perancangan Konseptual

Menurut Connolly dan Begg (2010, p467),

perancangan basis data konseptual

adalah proses

membuat suatu model dari data

yang digunakan pada suatu perusahaan,

yang terlepas dari semua pertimbangan fisik.

Menurut definisi di atas dapat diartikan bahwa perancangan konseptual adalah

proses merancang kebutuhan data sesuai dengan yang terjadi dunia nyata, yang terlepas

dari semua pertimbangan fisik.

Langkah – langkah di dalam perancangan basis data konseptual:

Langkah 1 : Membangun Model Data Konseptual.

Langkah ini bertujuan untuk membangun data model konseptual yang berasal dari data

yang dibutuhkan oleh perusahaan.

Adapun langkah – langkah dalam perancangan basis data konseptual sebagai berikut:

Langkah 1.1 Identifikasi tipe entity

Langkah ini bertujuan untuk mengidentifikasikan entity yang dibutuhkan

Langkah 1.2 Identifikasi tipe Relationsh

Langkah

ini

bertujuan

untuk

mengidentifikasikan

hubungan

penting

yang

ada

antara

entitas.

Langkah 1.3 Identifikasi dan menghubungkan atribut dengan entity atau tipe

Relationship

Langkah

ini

bertujuan

untuk

menghubungkan

atribut dengan

entitas

yang

sesuai atau

tipe hubungan.

Langkah 1.4 Menentukan atribut domain

Langkah

ini

bertujuan

untuk

menentukan

domains

untuk

atribut

dalam model data

konseptual.

Langkah 1.5 Menentukan atribut candidate, primary, dan alternate key

Langkah

ini bertujuan untuk

mengidentifikasi candidate key untuk tiap tipe entitas dan

jika ada lebih dari satu candidate key

maka pilih satu

untuk menjadi primary key dan

yang lainnya menjadi alternate keys.

Langkah

1.6 Mempertimbangkan

penggunaan

enhanced

modeling

concept

(optional)

Langkah ini bersifat optional, tujuan dari langkah ini adalah untuk mempertimbangkan

kegunaan dari

enhanced

modeling

concept,

seperti pecialization/generalization,

aggregation dan composition.

Langkah 1.7 Memeriksa redudansi pada model

Langkah ini bertujuan untuk memeriksa keberadan dari redudansi pada model.

Langkah ini memeriksa model data konseptual apakah terjadi duplikasi atau titik dengan

dua langkah yaitu :

• Memeriksa ulang relasi one-to-one,

• Menghilangkan relasi yang terduplikasi (redundant).

Langkah 1.8 Melakukan validasi pada model data konseptual lokal terhadap

transaksi pengguna

Langkah

ini

bertujuan

unuk

memastikan

model

data

konseptual

mendukung

transaksi

yang dibutuhkan.

Pemeriksaan ini dapat menggunakan dua langkah yaitu :

•

Mendeskripsikan transaksi,

•

Menggunakan jalur transaksi (pathways).

Gambar 2.21 Hasil Perancangan Basis Data Konseptual dengan Pathways.

(Sumber: Connolly dan Begg, 2010, p485)

Langkah 1.9 Meninjau ulang model data konseptual dengan pengguna

Langkah

ini

bertujuan

untuk

memeriksa

kembali

data

model

konseptual

dengan

pengguna nuntuk memastikan bahwa model merupakan gambaran dari data yang

dibutuhkan oleh perusahaan.

2.15.4.3.2 Perancangan Logikal

Menurut Connolly dan Begg (2010, p467), perancangan basis data logikal adalah

proses

membuat

model data yang digunakan dalam perusahaan berdasarkan spesifikasi

data model, tetapi terlepas dari DBMS tertentu dan pertimbangan fisikal lainnya.

Menurut definisi di atas dapat diartikan bahwa perancangan logikal adalah

pemeriksaan

data

model

konseptual

yang

telah dirancang agar

dapat digunakan oleh

perusahaan yang terlepas dari pertimbangan fisikal lainnya.

Langkah 2 : Membangun model data logikal

Membangun

model

data

logikal

lokal dari

model

data

konseptual

yang

merepresentasikan view tertentu dari perusahaan kemudian memvalidasi model ini untuk

memastikan agar

benar

secara structural

(penggunaan

teknik

normalisasi)

dan

untuk

memastikan bahwa model tersebut mendukung transaksi yang dibutuhkan.

Langkah 2.1 Menurunkan relasi untuk dua model logikal lokal

Langkah ini bertujuan membuat relasi untuk data model logical untuk mewakili entitas,

relationship, dan atribut yang telah diidentifikasi.

Pada tahap ini, mendefinisikan bagaimana relasi diperoleh untuk struktur yang mungkin

terjadi dalam model basis data konseptual sebagai berikut:

• Tipe entity kuat,

• Tipe entity lemah,

• Tipe relasi binary one-to-many (1:*),

• Tipe relasi binary one-to-one (1:1),

• Tipe relasi rekursif one-to-one (1:1),

• Tipe relasi superclass atau subclass,

• Tipe relasi binary many-to-many (*:*),

• Tipe relasi kompleks,

• Atribut multi-valued.

Langkah 2.2 Memvalidasi relasi – relasi dengan menggunakan normalisasi

Tujuan

dari

normalisasi

untuk memastikan

kumpulan

relasi

memiliki

atribut

yang

minimal dan cukup penting untuk mendukung kebutuhan data dari enterprise dan untuk

meningkatkan

model

yang

telah

terbentuk

agar

duplikasi

data

yang

tidak

diperlukan

dapat dihindari.

Langkah 2.3 Memvalidasi relasi – relasi terhadap transaksi pengguna

Langkah

ini bertujuan

untuk

memastikan relasi dalam data model

logical

mendukung

kebutuhan transaksi.

Langkah 2.4 Mendefinisikan integritas constraint

Langkah

ini bertujuan untuk

memeriksa integrity constraints yang digambarkan dalam

model data logical.

Integrity

constraint

adalah batasan yang digunakan untuk melindungi basis data dari

ketidaklengkapan,

ketidakakuratan,

atau

ketidakkonsistenan.

Ada

tipe integrity

constraint :

• Required data (data atau nilai yang valid),

• Batasan domain attribute,

• Multiplicity (batasan relasi antar data dalam database),

• Entity integrity (primary key tidak boleh null),

•

Referential integrity (foreign key pada suatu entity harus sesuai dengan candidate

key pada entitas lain),

• General constraints.

Langkah 2.5 Meninjau ulang model data logika lokal dengan pengguna

Langkah

ini bertujuan

untuk meninjau kembali

model data logical dengan user untuk

memastikan pengguna menyadari model tersebut sudah menggambarkan kebutuhan

data dari perusahaan.

Langkah 2.6 Menggabungkan

model –

model data logikal lokal ke dalam model

global

Menggabungkan

model

–

model data

logical

lokal

individu

dalam

sebuah

model

data global yang mewakili perusahaan tersebut.

Langkah 2.6.1 Menggabungkan model – model data logikal lokal ke dalam model

global

Langkah

ini bertujuan

untuk menggabungkan data model logical kedalam satu global

logical data model.

Langkah 2.6.2 Memvalidasi model data logikal global

Untuk memvalidasi relasi

yang dibuat dari

global data model logical menggunakan

teknik normalisasi untuk memastikan data model mendukung transaksi yang

dibutuhkan jika penting.

Langkah 2.6.3 Meninjau ulang model data logikal global dengan pengguna

Langkah ini bertujuan untuk memastikan bahwa

model

data

logikal

global

adalah

gambaran dari data yang dibutuhkan oleh perusahaan.

Langkah 2.7 Memeriksa kemungkinan pengembangan basis data di masa yang

akan datang

Langkah ini bertujuan untuk menentukan apakah ada perubahan yang signifikan yang

akan berubah di masa yang akan datang dan juga menunjukkan apakah model data

logikal global dapat mengakomodasi perubahan tersebut.

2.15.4.3.3 Perancangan Fisikal

Menurut Connolly dan Begg (2010, p523) perancangan basis data fisikal adalah

proses pembuatan deskripsi dan implementasi

basis

data

pada

media

penyimpanan

sekunder.

Proses

tersebut

menjelaskan

relasi

dasar,

perorganisasian file,

dan

indexes

yang digunakan untuk mencapai akses data yang efisien dan

integritas constraint yang

berhubungan, dan tingkat keamanan.

Menurut definisi di atas dapat diartikan bahwa perancangan fisikal adalah proses

penerapan rancangan logikal beserta index,

organisasi

file, batasan integritas, relasi

disarm dan

semua

yang

berhubungan

dengan

keamaan

pada

media

penyimpanan

sekunder

Langkah 3 Menerjemahkan model data logikal global untuk target DBMS.

Langkah ini bertujuan untuk menghasilkan suatu skema basis data relasional dari logikal

data model yang bisa diterapkan pada target DBMS.

Langkah 3.1 Mendesain relasi – relasi dasar

Langkah

ini

bertujuan

untuk

memutuskan

bagaimana

mempresentasikan

relasi

dasar

yang didefinisikan di model data logikal global ke target DBMS.

Langkah 3.2 Mendesain representasi dari data turunan

Langkah ini bertujuan untuk memutuskan bagaimana menggambarkan data turunan pada

data model logical ke dalam target DBMS.

Langkah 3.3 Mendesain batasan – batasan perusahaan

Langkah ini bertujuan untuk mendesain batasan – batasan perusahaan untuk target

DBMS.

Langkah 4 Merancang File Organization dan Index

Langkah ini bertujuan untuk menentukan file organisasi yang optimal untuk menyimpan

relasi – relasi dasar dan indeks –

indeks yang dibutuhkan

untuk mencapai kinerja yang

dapat diterima,

yaitu dengan cara dimana relasi –

relasi dan tupples

(baris – baris dari

sebuah relasi) yang disimpan pada media penyimpanan sekunder.

Langkah 4.1 Menganalisa transaksi – transaksi

Langkah ini bertujuan untuk memahami bahwa

fungsionalitas dari transaksi – transaksi

yang

akan

dijalankan dalam basis

data

untuk

menganalisa transaksi

–

transaksi

yang

penting.

Dalam menganalisa

transaksi,

kita mencoba

mengidentifikasikan

kriteria

performance, seperti :

•

Transaksi yang berjalan secara teratur dan akan mempunyai dampak uang signifikan

pada performance,

• Transaksi yang krisis pada operasi bisnis,

•

Waktu selama sehari atau seminggu ketika akan ada permintaan yang tinggi dibuat

pada basis data (disebut peak load).

Langkah 4.2 Memilih organisasi file

Langkah ini bertujuan untuk menentukan file organisasi yang efisien untuk setiap relasi

dasar. Ada 5 tipe organisasi file :

• Heap,

• Hash,

• Indexed Sequential Office Access Method (ISAM),

• B

-tree,

• Cluster.

Langkah 4.3 Memilih indeks – indeks

Langkah

ini

bertujuan

untuk

menentukan

apakah

dengan

menambah

indeks

–

indeks

akan meningkatkan kinerja dari sistem.

Langkah 4.4 Memperkirakan kebutuhan disk space

Langkah

ini bertujuan untuk

memperkirakan jumlah disk space

yang akan dibutuhkan

basis data.

Langkah 5 Mendesain user views

Langkah

ini

bertujuan

untuk

mendesain

user

views

yang

telah

diidentifikasi

selama

tahap requirements collection and analysis dari database development lifecycle.

Langkah 6 Merancang mekanisme keamanan

Langkah

ini

bertujuan

untuk

merancang

mekanisme

keamanan

untuk database

seperti

yang

telah

ditentukan

oleh

pengguna

selama

tahap

requirement

and

collection dari

database development lifecycle.

2.15.5 DBMS Selection

Menurut Connolly dan Begg

(2010, p325), Pemilihan DBMS

yang tepat

untuk

mendukung aplikasi basis data.

Dari

pengertian

diatas

dapat

disimpulkan bahwa pada tahap ini DBMS

dibandingkan dan dipilih mana yang sesuai dengan kebutuhan perusahaan agar

mendukung aplikasi perusahaan.

Tahap – tahap utama untuk memilih DBMS :

•

Mendefinisikan terminology studi referensi,

•

Mendaftar dua atau tiga produk,

•

Evalusai produk,

•

Rekomendasi pilihan dan laporan produk.

2.15.6 Application Design

Menurut Connolly

dan

Begg

(2010,

p329),

desain

aplikasi adalah desain user

interface dan program aplikasi yang menggunakan dan memproses basis data.

Dari pengertian di atas dapat disimpulkan desain aplikasi adalah tahapan dimana

percanangan aplikasi yang terhubung dengan basis data perusahaan.

Desain basis data dan aplikasi

merupakan aktifitas parallel

yang meliputi dua aktifitas

penting, yaitu :

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

keterangan

karakteristik high-level dari suatu transaksi yang dibutuhkan pada basis data.

Terdapat tiga tipe transaksi, yaitu :

•

Retrievel transaction, digunakan untuk pemanggilan (retrievel) 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 di dalam database.

•

Mixed transaction, meliputi pemanggilan dan perubahan data.

2. User Interface Design

Beberapa aturan pokok dalam pembuatan user interface :

• Meaningful

title,

diusahakan

pemberian

nama

suatu

form

cukup

jelas

menerangkan kegunaan 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 sequenceing of fields, fields yang saling berhubungan

ditempatkan pada form/report yang sama. Urutan field harus logis dan konsisten.

•

Visually applealing 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,

terminology

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.

• Convenient

cursor movement, user

dapat

dengan

mudah

menjalankan operasi

yang diinginkan dengan menggerakan cursor 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 market clearly.

• Explanatory messages for fields, ketika user meletakkan cursor pada suatu field,

maka keterangan mengenai field tersebut harus dapat dilihat.

• Completion signal, indikator yang menjelaskan bahwa suatu proses telah selesai

dilaksanakan.

2.15.7 Prototyping

Menurut Connolly dan Begg (2010, p333), Prototyping adalah membuat model

kerja suatu aplikasi basis data. yang tidak memiliki semua fitur yang dimiliki oleh sistem

final

Dari kesimpulan diatas dapat disimpulkan bahwa prototype adalah suatu model

aplikasi basis data yang memiliki fitur minimal.

Terdapat dua macam strategi prototyping yaitu :

1. Requirements

prototyping,

menggunakan

prototype

untuk

menentukan

kebutuhan

dari aplikasi basis data yang diinginkan dan ketika kebutuhan itu terpenuhi maka

prototype akan dibuang

2. Evolutionary

prototyping,

digunakan

untuk

tujuan

yang

sama.

Perbedaannya,

prototype tidak dibuang tetapi dengan pengembangan lanjutan menjadi aplikasi basis

data yang digunakan.

2.15.8 Implementation

Menurut Connolly

dan

Begg

(2010,

p333),

Implementasi

merupakam realisasi

fisik dari basis data dan desain aplikasi.

Dari pengertian diatas dapat disimpulkan

bahwa

implementasi

merupakan

penerapan rancangan sistem basis data pada perusahaan.

2.15.9 Data Conversation and Loading

Menurut Connolly dan Begg (2010, p334), pemindahan data yang ada ke dalam

basis

data baru

dan

mengkonversikan

aplikasi

yang

ada

agar

dapat digunakan

pada

basis data yang baru.

Dari pengertian diatas dapat disimpulkan bahwa konversi data adalah proses

pemindahan data pada perusahaan yang telah ada sebelumnya ke sistem basis data yang

telah dirancang.

2.15.10 Testing

Menurut Connolly dan Begg (2010, p334), testing adalah suatu proses eksekusi

program aplikasi dengan tujuan untuk menemukan kesalahan.

Dari

pengertian

atas

dapat

disimpulkan

bahwa testing adalah

suatu

proses

pencarian kesalahan yang tidak terduga untuk diperbaiki.

2.15.11 Operational Maintenance

Menurut Connolly dan Begg (2010, p335), Suatu proses pengawasan dan

pemeliharaan sistem setelah instalasi.

Menurut definisi di

atas dapat diartikan bahwa operational maintenance adalah

proses yang dilakukan untuk menjaga performa sistem yang sedang berjalan.

Pengawasan dan pemeliharaan sistem meliputi :

• Pengawasan performa sistem, jika performa menurun maka memerlukan perbaikan

atau pengaturan ulang basis data.

• Pemeliharaan dan pembaharuan sistem basis data (jika dibutuhkan).

2.16 Anomaly

Menurut

Hoffer,

Prescot

dan

topi

(2009,

p251), anomaly

adalah

error

atau

ketidakkonsistensian yang terjadi pada saat pengguna berusaha untuk meng-update tabel

yang memiliki data redudan.

Dari

pengertian

diatas

dapat

disimpulkan, anomaly

adalah

kesalahan

atau

ketidakkonsistesian

yang terjadi akibat pengguna memasukan, atau merubah data

yang

ada di dalam database.

2.17 Data Flow Diagram (DFD)

Menurut Romney (2006, p156), data flow diagram (DFD) menggambarkan

aliran

secara

grafis

data

dalam suatu

organisasi.

DFD

digunakan

untuk

mendokumentasikan

sistem yang

berjalan

dan

untuk

membuat

perencanaan

dan

perancangan sistem yang baru.

Dari pengertian diatas dapat disimpulkan, bahwa DFD adalah diagram yang

menggambarkan arus data pada yang digunakan untuk mendokumentasikan sistem yang

sedang berjalan

yang digunakan

untuk

membuat perencanaan dalam merancang sistem

yang baru.

2.18

Flowchart

Menurut Romney (2006, p70-73), flowchart adalah sebuah teknik analisis yang

digunakan untuk

menjelaskan beberapa aspek dari sistem informasi dalam bentuk

yang

jelas, ringkas, dan

logis. Flowchart menggunakan suatu kumpulan simbol standar

yang

digunakan

untuk

mendeskripsikan

gambaran

dari

proses

transaksi

sebuah

perusahaan,

dan aliran data melalui sistem.

Menurut definisi di atas dapat diartikan bahwa flowchart

adalah teknik

penggambaran alur dokumen dalam suatu proses bisnis perusahaan secara sequensial

yang digunakan untuk kepentingan analisis.

Simbol Flowchart dapat dibagi menjadi empat kategori yaitu :

•

Input/ output merepresentasikan sebuah alat atau media yang menyediakan

masukkan atau merekam hasil dari proses operasi.

•

Processing

symbol

menunjukkan

tipe dari suatu

alat

yang

digunakan

untuk

memproses

data

atau

mengidentifikasikan

kapan

data itu selesai

diproses

secara

manual.

•

Storage symbol menggambarkan alat – alat

yang digunakan

untuk menyimpan data

yang tidak sedang digunakan.

•

Flow

dan miscellaneous

symbol

mengidentifikasikan

aliran data

dan

barang.

Mempresentasikan beberapa operasi dari kapan aliran data dimulai dan diakhiri,

kapan keputusan dibuat, dan kapan memasukan catatan yang benar pada suatu aliran

data.

2.19 State Transition Diagram (STD)

Menururt

Whitten

(2004,

p636),

state

transition

diagram adalah

alat

yang

digunakan untuk menggambarkan urutan variasi screen yang dapat terjadi selama satu

sesi pengguna.

Menurut definisi di atas dapat diartikan State transition diagram adalah diagram

yang menggambarkan kejadian yang dapat terjadi pada suatu screen dalam suatu

aplikasi.

2.20 Fungsi Penjualan

Menurut

Mulyadi

(2001,

p211),

dalam transaksi

penjualan

kredit,

fungsi

ini

bertanggung

jawab

untuk

menerima

surat order

dari

pembeli,

mengedit

order dari

pelanggan untuk menambahkan informasi yang ada pada surat order tersebut, meminta

otorisasi kredit, menentukan tanggal pengiriman dan dari gudang manakah barang akan

dikirim.

Dari kesimpulan diatas dapat disimpulkan, fungsi penjualan bertanggung jawab

untuk mencatat semua transaksi penjualan yang diberikan oleh pelanggan yang berupa

surat order dan menentukan tanggal pengirimannya.

2.21

Fungsi Kredit

Menurut Mulyadi (2001, p211), fungsi ini berada dibawah fungsi keuangan yang

dalam transaksi

penjualan

kredit,

bertanggung

jawab

untuk

meneliti

status

kredit

pelanggan dan memberikan otorisasi pemberian kredit kepada pelanggan.

Dari pengertian diatas dapat

disimpulkan,

fungsi

kredit

adalah

fungsi

yang

bertanggung jawab mencatat semua kredit serta pemberlian otorisasi kepada pelanggan.

2.22

Fungsi Persediaan

Menurut

Mulyadi (2001,

p533),

sistem persediaan

memiliki tujuan

untuk

mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini berkaitan erat

dengan

sistem penjualan,

sistem retur

penjualan,

sistem pembelian,

sistem retur

pembelian

sistem akutansi

biaya

produksi.

Dalam

perusahaan

manufaktur,

persediaan

terdiri dari persediaan produk jadi. Persediaan suku cadang, Dalam perusahaan dagang,

persediaan hanya terdiri dari satu golongan yanitu persediaan barang dagangan (produk)

yang

merupakan barang yang dibeli terlebih dahulu dengan tujuan dijual kembali dan

barang

yang dijual

kembali

tersebut dijual

dengan

harga

yan

lebih

tinggi

dari

harga

awal.

Dari pengertian diatas dapat disimpulkan, sistem persediaan bertugas untuk

mencatat tiap barang keluar masuk gudang yang dicacat berdasarkan pembelian dan

penjualan yang dilakukan oleh perusahaan.

2.23 Fungsi Pembelian

Menurut

Mulyadi

(2001,

p300),

Fungsi pembelian

bertanggung

jawab

untuk

memperoleh informasi mengenai harga barang. menentukan pemasok yang dipilih dalam

pengadaan barang dan mengeluarkan

order pembelian

kepada

pemasok

yang dipilih.

Fungsi pembelian berada di tangan bagian pembelian.

Menurut definisi di atas dapat diartikan Fungsi pembelian adalah suatu fungi

yang menyimpan informasi mengenai order pembelian beserta deskripsi barang yang

bersangkutan dengan pemasoknya, yang di dilakukan oleh bagian pembelian.