2012101226IFBab2001

BAB 2

LANDASAN TEORI

2.1 Cause Effect Analysis

Cause effect analysis adalah sebuah teknik dimana masalah dipelajari untuk

mengetahui penyebab dan akibat dari permasalah tersebut.

Permasalahan harus

dianalisis penyebab dan akibatnya sampai waktu penyebab dan akibat tidak

menghasilkan gejala masalah lain. Cause effect analysis menyebabkan pemahaman

yang benar mengenai masalah dan dapat mengarah pada solusi yang tidak begitu

jelas, tetapi lebih kreatif dan berharga. (Whitten dan Bentley, 2007, p180)

2.2 Database System Development Lifecycle

Ketika software yang dikembangkan database system maka lifecycle yang

digunakan adalah database system development lifecycle

(DSDLC). Sebuah

database system merupakan komponen fundamental dari organisasi yang besar

dengan sistem informasi yang luas, database system development lifecycle terkait

dengan lifecycle dari information system.

Perlu

diingat bahwa tahapan dalam database system development lifecycle

tidak

harus berurutan, namun

juga dapat melibatkan beberapa pengulangan ke

tahapan sebelumnya melalui feedback loops.

Untuk

database system,

dengan

user

yang

sedikit,

lifecycle tidak

perlu

kompleks.

Ketika

mendesain

sebuah

database system

yang

sedang

atau besar

dengan sepuluh sampai

ribuan user

menggunakan ratusan query dan program

aplikasi, lifecycle dapat menjadi sangat kompleks. (Connoly dan Begg, 2010, p312)

Gambar 2.1 Database System Development Lifecycle

(Sumber : Connoly dan Begg, 2010, p314)

2.2.1

Database Planning

Database planning merupakan kegiatan pengaturan yang

memungkinkan tahapan –

tahapan database system development lifecycle

direalisasikan seefektif dan seefisien mungkin.

2.2.2

System Definition

System definition

menggambarkan ruang lingkup dan batasan dari

database system dan user view utama.

User view mendefinisikan apa yang dibutuhkan oleh database system

dari sudut pandang peranan pekerjaan tertentu (seperti Manager atau

Supervisor) atau area aplikasi perusahaan (seperti marketing, personnel, atau

stock control).

2.2.3

Requirement Collection and Analysis

Requirement collection and analysis merupakan proses mengumpulkan

dan menganalisis informasi mengenai bagian organisasi yang didukung oleh

database system,

dan menggunakan informasi ini untuk mengidentifikasi

kebutuhan untuk sistem yang baru.

2.2.4

Database Design

Database design merupakan proses membuat rancangan yang akan

mendukung pernyataan misi dan tujuan misi suatu perusahaan untuk

database system yang diperlukan.

2.2.5

DBMS Selection (Optional)

Memilih sebuah DBMS yang cocok untuk mendukung database

system.

2.2.6

Application Design

Application design merancang

user interface dan aplikasi program

yang digunakan dan memproses database.

2.2.7

Prototyping (Optional)

Prototyping adalah membangun sebuah model kerja dari database

system. Tujuan utama dari

mengembangkan prototype database system

adalah untuk memungkinkan pengguna menggunakan prototype untuk

mengidentifikasi fitur yang bekerja pada sistem bekerja dengan baik atau

tidak, dan apabila memungkinkan untuk menyarankan perbaikan atau

bahkan fitur baru untuk database system.

2.2.8

Implementation

Implementation adalah realisasi fisikal dari database dan rancangan

aplikasi. stock control).

2.2.9

Data Convertion and Loading

Memindahkan data yang ada ke dalam database yang baru dan

mengubah aplikasi yang ada untuk

dijalankan pada database yang baru.

stock control).

2.2.10

Testing

Testing merupakan proses menjalankan database system dengan

tujuan untuk menemukan error.

2.2.11

Operational Maintenance

Operational maintenance merupakan proses mengawasi dan

memelihara database system diikuti dengan instalasi.

2.3 Perancangan Basis Data

Database

adalah koleksi bersama dari data yang terkait secara logis dan

deskripsi dari data tersebut, yang dirancang untuk memenuhi kebutuhan informasi

suatu organisasi. (Connolly dan Begg, 2010, p65)

Perancangan database

adalah proses menciptakan desain untuk sebuah

database yang akan mendukung operasi dan tujuan dari suatu perusahaan. Dua

pendekatan utama untuk perancangan database, yaitu bottom – up dan top – down.

(Connolly dan Begg, 2010, p320)

Pendekatan Bottom – Up

Pendekatan bottom –

up dimulai dari tingkat dasar atribut, yang melalui

hubungan analisis antar atribut, yang dikelompokkan ke dalam hubungan yang

mewakili tipe entitas dan hubungan antar entitas. Pendekatan bottom – up tepat

untuk rancangan database sederhana dengan jumlah atribut yang relatif kecil.

Namun, pendekatan ini menjadi sulit ketika diterapkan pada perancangan

database yang lebih kompleks.

Pendekatan Top - Down

Strategi yang tepat untuk perancangan database yang lebih kompleks adalah

dengan menggunakan pendekatan top –

down. Pendekatan top –

down

diilustrasikan menggunakan konsep Entity Relationship Model dimulai dengan

mengidentifikasi entitas dan hubungan antar entitas.

Perancangan database terdiri dari tiga tahap utama, yaitu perancangan

konseptual, perancangan logikal, dan perancangan fisikal. (Connolly and Beg, 2010,

p322)

2.3.1

Entity – Relationship (ER) Modelling

Entity -

Relationship (ER) Modelling

merupakan pendekatan top –

down

untuk model perancangan

database yang dimulai dengan

mengidentifikasi data penting yang disebut entitas dan hubungan diantara

data yang harus direpresentasikan di dalam model. Kemudian menambahkan

lebih banyak detail, seperti informasi yang terus diinginkan mengenai entitas

dan hubungan yang disebut atribut dan setiap constraint

pada entitas,

hubungan, dan atribut. (Connolly dan Begg, 2010, p371)

A. Tipe Entitas

Tipe entitas adalah kumpulan objek

dengan sifat yang sama,

dimana

mereka diidentifikasi oleh perusahaan yang mempunyai

keberadaan yang mandiri. Tipe entitas merepresentasikan kumpulan

objek di

dalam dunia nyata dengan sifat yang sama, objek dengan

physical existence

(nyata) dan objek

dengan conceptual existence

(abstrak). (Connolly dan Begg, 2010, p372)

Tabel 2.1 Contoh physical existence dan conceptual existence

Physical Existence

Pasien Karyawan

Dokter Obat

Conceptual Existence

Rawat Jalan Penjualan

Rawat Inap Rekam Medik

B. Tipe Hubungan

Tipe hubungan adalah suatu set asosiasi yang bermakna diantara

tipe entitas. (Connolly dan Begg, 2010, p374)

Derajat Tipe Hubungan (Degree of Relationship Type)

Tingkat hubungan menunjukkan jumlah jenis entitas yang

terlibat dalam suatu hubungan.

Oleh karena itu, derajat

tipe

hubungan menentukan jumlah dari tipe entitas yang terlibat dalam

relationship.

Hubungan dari derajat dua (degree two) disebut binary.

Binary relationship menunjukkan dua tipe entitas yang

berpartisipasi. Hubungan dari derajat tiga (degree three) disebut

ternary. Ternary relationship menunjukkan tiga tipe entitas yang

berpartisipasi. Hubungan dari derajat empat (degree four) disebut

quaternary. Quaternary relationship menunjukkan empat tipe

entitas yang berpartisipasi.

Hubungan Rekursif (Recursive Relationship)

Tipe hubungan yang merupakan tipe entitas yang sama yang

berpartisipasi dalam lebih dari satu kali peran yang berbeda.

C. Atribut

Atribut adalah property dari sebuah entitas atau tipe hubungan.

Domain adalah setiap atribut yang terkait dengan sekumpulan nilai.

Atribut dapat diklasifikasikan sebagai berikut :

Simple dan Composite Attributes

Simple atribut adalah atribut yang tersusun dari komponen

tunggal. Misalnya : nama pasien rumah sakit.

Composite atribut adalah atribut yang tersusun dari banyak

komponen. Misalnya : alamat pasien rumah sakit.

Single – Valued Attributes dan Multi – Valued Attributes

Single –

valued atribut adalah atribut yang memiliki nilai

tunggal untuk setiap kejadian sebuah tipe entitas. Misalnya : nomor

rekam medik pasien rumah sakit.

Multi –

valued atribut adalah atribut yang memiliki banyak

nilai untuk setiap kejadian sebuah tipe entitas. Misalnya : nomor

telepon pasien rumah sakit

Derived Attributes

Derived atribut adalah atribut yang merepresentasikan nilai

yang diturunkan dari nilai atribut yang terkait atau satu set atribut,

tidak perlu dalam tipe entitas yang sama. Misalnya: subtotal

pembayaran layanan rumah sakit.

D. Keys

Candidate key adalah set atribut minimal yang diidentifikasi secara

unik dari masing – masing kejadian tipe entitas.

Primary key adalah candidate key yang terpilih.

Alternate key adalah candidate key yang terdiri dari dua atau lebih

atribut yang tidak terpilih. (Connolly dan Begg, 2010, p381)

E. Tipe Entitas Strong dan Weak

Strong entity type

Jenis entitas yang tidak tergantung pada keberadaan beberapa

jenis entitas lainnya. Jenis entitas disebut sebagai strong entity type

jika keberadaannya tidak bergantung pada keberadaan entitas jenis

lain. Strong entity type terkadang disebut sebagai parent, owner, atau

dominant entities (Connolly dan Begg, 2010, p383)

Weak entity type

Jenis entitas yang keberadaannya tergantung pada beberapa tipe

entitas lainnya. Weak entity type bergantung pada keberadaan entitas

jenis lain. Karakteristik dari weak entity type

adalah bahwa setiap

kemunculan entitas tidak dapat diidentifikasi secara unik hanya

dengan menggunakan atribut yang terkait dengan jenis entitas. Weak

entity type terkadang disebut sebagai child, dependent, or subordinate

entities. (Connolly dan Begg, 2010, p384)

F. Structural Constraint

Tipe hubungan biasanya mempunyai constraint tertentu yang

membatasi kemungkinan kombinasi dari entitas yang mungkin

berpartisipasi dalam sekumpulan hubungan yang terkait. (Elmasri and

Navathe, 2000, p56)

Tipe utama dari constraint dalam relationship disebut

multiplicity. Multiplicity adalah jumlah kemungkinan terjadinya suatu

tipe entitas yang mungkin berhubungan dengan kejadian tunggal dari

sebuah tipe entitas terkait melalui hubungan tertentu.

(Connolly dan

Begg, 2010, p385)

One – to – one (1:1) Relationship

Pada atribut dari one – to – one (1:1) relationship dapat pindah

ke salah satu tipe entitas yang berpartisipasi.

One – to – many (1:*) Relationship

Pada tipe hubungan 1:*, hubungan atribut hanya dapat pindah

ke tipe entitas pada bagian – * dari sebuah hubungan.

Many – to – many (*:*) Relationship

Untuk tipe hubungan *:*, beberapa atribut dapat ditentukan

oleh kombinasi dari entitas yang berpartisipasi dalam hubungan

instance, bukan oleh satu entitas saja. Atribut tersebut harus

ditentukan sebagai hubungan atribut.

G. Masalah pada Model ER

Ada masalah yang mungkin muncul ketika membuat model ER,

masalah ini disebut sebagai connection traps, dan biasanya muncul

karena salah menafsirkan arti dari hubungan tertentu. Connection traps

dibagi menjadi dua tipe utama, yaitu fan traps dan chasm traps.

Fan traps

Model yang merepresentasikan sebuah hubungan antara tipe

entitas tetapi langkah yang memastikan suatu kejadian tertentu tidak

jelas.

Chasm traps

Model yang merepresentasikan sebuah hubungan antara tipe

entitas

tetapi tidak ada jalan yang menunjukkan keberadaan

kejadian pada entitas tersebut.

Gambar 2.2 Entity Relationship (ER) diagram

(Sumber : Connoly dan Begg, 2010, p373)

2.3.2

Normalisasi

Normalisasi data dapat dilihat sebagai sebuah proses menganalisis

skema relasi yang diberikan berdasarkan ketergantungan fungsi (functional

dependencies) dan primary key

untuk meminimalkan perulangan dari

property / atribut dan meminimalkan update anomalies. (Elmasri and

Navathe, 2004, p313) Update anomalies diklasifikasikan menjadi insertion,

deletion, dan modification anomalies.

Tabel 2.2 StaffBranch Relation

(Sumber : Connoly dan Begg, 2010, p419)

staffNo

staffName

position

salary

branchNo

bAddress

SL21

John White

Manager

30000

B005

22 Derr Rd, London

SG37

Ann Beech

Assistant

12000

B003

163 Main St, Glasgow

SG14

David Ford

Supervisor

18000

B003

163 Main St, Glasgow

SA9

Mary Howe

Assistant

9000

B007

16 Argyll St, Aberdeen

SG5

Susan Brand

Manager

24000

B003

163 Main St, Glasgow

SL41

Julie Lee

Assistant

9000

B005

22 Derr Rd, London

A. Insertion Anomalies

Terdapat dua tipe utama insertion anomalies, dapat

diilustrasikan dengan menggunakan StaffBranch Relation pada tabel 2.2.

(Connoly dan Begg, 2010, p419)

Untuk memasukkan rincian anggota baru dari staf ke dalam relasi

StaffBranch, harus memasukan juga detail dari cabang dimana staf

akan berada

Untuk memasukkan rincian cabang baru yang pada saat itu belum

mempunyai anggota dari staf di dalam relasi StaffBranch, perlu

untuk memasukkan

null ke atribut staf, seperti staffNo. Namun

staffNo adalah primary key dari relasi StaffBranch,memasukkan null

untuk melanggar entity integrity dan tidak diperbolehkan.

B. Delete Anomalies

Jika menghapus sebuah baris dari relasi StaffBranch

yang

merepresentasikan anggota lama dari staf yang berlokasi pada sebuah

cabang, rincian mengenai cabang tersebut juga akan hilang dari

database. (Connoly dan Begg, 2010, p419)

C. Modification Anomalies

Jika ingin mengubah nilai dari salah satu atribut pada cabang

tertentu di dalam relasi StaffBranch. Sebagai contoh, alamat dari cabang

yang bernomor B003, update

harus dilakukan pada semua baris yang

berlokasi pada cabang tersebut. (Connoly dan Begg, 2010, p420)

D. Functional Dependencies

Ketergantungan fungsi (Functional Dependencies) adalah

pembatas antara dua set atribut dari database. (Elmasri and Navathe,

2004, p304)

Functional dependencies dibagi menjadi 3, yaitu full

functional dependency, partial dependency, transitive dependency.

Full functional dependency

Full functional dependency menunjukkan jika A dan B adalah atribut

dari sebuah relasi, B merupakan full functionally dependent pada A,

tetapi tidak pada setiap bagian dari A. (Connoly dan Begg, 2010,

p423)

Full functional dependency dapat ditunjukkan sebagai berikut :

staffNo

branchNo

Partial dependency

jika terdapat beberapa atribut yang bisa

dihilangkan dari A dan meskipun dependency masih dimiliki.

(Connoly dan Begg, 2010, p423)

Contoh diatas bukan merupakan full functional dependency, karena

branchNo

juga functionally dependency pada subset dari (staffNo,

sName) yaitu staffNo.

Transitive dependency

Transitive dependency merupakan sebuah kondisi dimana A, B, dan

C adalah atribut dari sebuah relasi seperti A

B dan B C, maka

C adalah transitive dependent

pada A melalui B.

(Connoly dan

Begg, 2010, p424)

staffNo sName, Position, salary, branchNo, bAddress

Transitive dependency branchNo

bAddress terjadi pada staffNo

melalui branchNo.

E. Unnormalized Form (UNF)

Tabel

yang berisi satu atau lebih grup yang berulang.

Pada

tahap ini mentransfer

data dari sumber menjadi

format tabel dengan

baris dan kolom. (Connolly dan Begg, 2010, p430)

staffNo, sName

branchNo

bAddress

Tabel 2.3 ClientRental Unnormalized Table

(Sumber : Connoly dan Begg, 2010, p432)

client

cName

property

pAddress

rentStart

rentFinish

rent

owner

oName

CR76

John

Kay

PG4

6 Lawrence

St, Glasglow

1-Jul-07

31-Aug-08

350

CO40

Tina

Murphy

PG16

5 Novar Dr,

Glasglow

1-Sep-08

1-Sep-09

450

CO93

Tony

Shaw

CR56

Aline

Stewart

PG4

6 Lawrence

St, Glasglow

1-Sep-06

10-June-

350

CO40

Tina

Murphy

PG36

2 Manor Rd,

Glasglow

10-Oct-

1-Dec-08

375

CO93

Tony

Shaw

PG16

5 Novar Dr,

Glasglow

1-Nov-

10-Aug-10

450

CO93

Tony

Shaw

Berdasarkan gambar diatas struktur dari repeating group adalah sebagai

berikut :

Repeating Group = (propertyNo, pAddress, rentStart, rentFinish, rent,

ownerNo, oName)

F. First Normal Form (1NF)

1NF didefinisikan untuk melarang atribut bernilai ganda,

komposit atribut, dan kombinasi keduanya. 1NF menyatakan bahwa

domain

dari atribut harus dan hanya mencakup nilai atomic

(tidak

terpisahkan) dan nilai – nilai atribut dalam tuple harus nilai tunggal dari

domain atribut tersebut. Dengan kata lain, 1NF melarang “hubungan

dalam hubungan”. Nilai –

nilai atribut yang hanya diijinkan oleh 1NF

adalah nilai atomic tunggal. (Elmasri and Navathe, 2004, p315)

Tabel 2.4 1NF Client

(Sumber : Connoly dan Begg, 2010, p433)

clienNo

cName

CR76

John Kay

CR56

Aline Stewart

Tabel 2.5 1NF PropertyRentalOwner

(Sumber : Connoly dan Begg, 2010, p433)

client

property

pAddress

rentStart

rentFinish

rent

owner

oName

CR76

PG4

6 Lawrence St,

Glasglow

1-Jul-07

31-Aug-08

350

CO40

Tina

Murphy

CR76

PG16

5 Novar Dr,

Glasglow

1-Sep-08

1-Sep-09

450

CO93

Tony

Shaw

CR56

PG4

6 Lawrence St,

Glasglow

1-Sep-06

10-June-

350

CO40

Tina

Murphy

CR56

PG36

2 Manor Rd,

Glasglow

10-Oct-

1-Dec-08

375

CO93

Tony

Shaw

CR56

PG16

5 Novar Dr,

Glasglow

1-Nov-

10-Aug-10

450

CO93

Tony

Shaw

Hasil dari relasi 1NF adalah sebagai berikut :

Client (clientNo, cName)

PropertyRentalOwner (clientNo, propertyNo, pAddress, rentStart,

rentFinish, rent, ownerNo, oName)

H. Second Normal Form (2NF)

2NF didasarkan pada konsep full functional dependency.

Ketergantungan fungsional X Y akan full functional dependency jika

menghapus atribut A dari X menyebabkan ketergantungan tersebut

menjadi tidak ada. Berarti untuk setiap atribut A bagian dari X secara

fungsional tidak menentukan Y. Sebuah ketergantungan fungsional akan

partial dependency jika beberapa atribut A bagian dari X dapat

dihilangkan dan ketergantungan tetap terjaga. (Elmasri and Navathe,

2004, p318)

Untuk hubungan dimana primary key mengandung

beberapa atribut, tidak ada atribut nonkey yang boleh bergantung secara

fungsional pada bagian primary key.

Tabel 2.6 2NF Client

(Sumber : Connoly dan Begg, 2010, p435)

clienNo

cName

CR76

John Kay

CR56

Aline Stewart

Tabel 2.7 2NF Rental

(Sumber : Connoly dan Begg, 2010, p435)

clientNo

propertyNo

rentStart

rentFinish

CR76

PG4

1-Jul-07

31-Aug-08

CR76

PG16

1-Sep-08

1-Sep-09

CR56

PG4

1-Sep-06

10-June-07

CR56

PG36

10-Oct-07

1-Dec-08

CR56

PG16

1-Nov-09

10-Aug-10

Tabel 2.8 2NF PropertyOwner

(Sumber : Connoly dan Begg, 2010, p435)

propertyNo

pAddress

rent

ownerNo

oName

PG4

6 Lawrence St,

Glasglow

350

CO40

Tina

Murphy

PG16

5 Novar Dr,

Glasglow

450

CO93

Tony Shaw

PG36

2 Manor Rd,

Glasglow

375

CO93

Tony Shaw

Relasi yang didapat adalah sebagai berikut :

Client (clientNo, cName)

Rental (clientNo, propertyNo, rentStart, rentFinish)

PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName)

Third Normal Form (3NF)

3NF didasarkan pada konsep transitive dependency.

Ketergantungan fungsional X Y dalam skema relasi R akan transitive

dependency jika ada satu set atribut Z yang bukan candidate key ataupun

subset dari key pada R, dan kedua X Z dan Z Y tetap bertahan.

(Elmasri and Navathe, 2004, p319) Relasi tidak boleh memiliki atribut

nonkey yang bergantung secara fungsional pada atribut nonkey lainnya.

Tidak boleh ada transitive dependency dari atribut nonkey pada primary

key.

Tabel 2.9 3NF PropertyForRent

(Sumber : Connoly dan Begg, 2010, p436)

propertyNo

pAddress

rent

ownerNo

PG4

6 Lawrence St,

Glasglow

350

CO40

PG16

5 Novar Dr,

Glasglow

450

CO93

PG36

2 Manor Rd,

Glasglow

375

CO93

Tabel 2.10 3NF Owner

(Sumber : Connoly dan Begg, 2010, p436)

ownerNo

oName

CO40

Tina

Murphy

CO93

Tony Shaw

CO93

Tony Shaw

Hasil dari relasi 3NF adalah sebagai berikut :

Client (clientNo, cName)

Rental (clientNo, propertyNo, rentStart, rentFinish)

PropertyForRent (propertyNo, pAddress, rent, ownerNo, oName)

Owner (ownerNo, oName)

2.3.3

Perancangan Basis Data Konseptual

Proses membangun data model yang digunakan dalam suatu

perusahaan. (Connolly dan Begg, 2010, p322)

Tujuan dari perancangan basis data konseptual adalah untuk

membangun model data konseptual dari data yang

dibutuhkan oleh

perusahaan. Perancangan basis data konseptual terdiri dari langkah –

langkah berikut ini :

Langkah 1 : Membangun model data konseptual

1.1Mengidentifikasi tipe entitas

Tipe entitas dapat diketahui dengan mengidentifikasi kata benda,

mencari objek utama seperti orang (people), tempat (place), atau konsep

yang menarik (concept of interest). Tahapan ini bertujuan untuk

mengidentifikasi tipe entitas yang dibutuhkan sesuai dengan spesifikasi

kebutuhan pengguna.

1.2Mengidentifikasi tipe hubungan

Bertujuan untuk mengidentifikasi hubungan (relationship) penting

yang ada diantara tipe entitas.

Tipe hubungan dapat diindikasikan

dengan kata kerja atau ekspresi verbal (verbal expression).

1.3Mengidentifikasi dan menghubungkan atribut dengan entitas atau

tipe hubungan

Bertujuan untuk menghubungkan atribut dengan entitas dan tipe

hubungan yang sesuai. Atribut dapat diklasifikasikan sebagai simple /

composite, single – valued / multi – valued, atau derived.

1.4Menentukan domain atribut

Bertujuan menentukan domain untuk

atribut dalam model data

konseptual. Domain atribut adalah himpunan nilai yang diijinkan untuk

satu atau lebih atribut.

1.5Menentukan atribut candidate, primary dan alternate key

Bertujuan untuk mengidentifikasi candidate key(s) untuk setiap tipe

entitas dan, jika ada lebih dari satu candidate key, pilih satu untuk

menjadi primary key dan yang lainnya sebagai alternate keys.

1.6Mempertimbangkan penggunaan enhanced modelling concepts

(optional step)

Bertujuan untuk mempertimbangkan penggunaan dari enhanced

modelling concepts, seperti specialization/generalization, aggregation,

dan composition.

1.7Memeriksa model terhadap redundancy

Bertujuan untuk mengecek adanya redundancy pada sebuah model.

1.8Memvalidasikan model data konseptual terhadap transaksi

pengguna

Bertujuan

untuk memastikan model data konseptual mendukung

transaksi yang dibutuhkan.

Dua kemungkinan pendekatan untuk

memastikan model data konseptual mendukung transaksi yang

dibutuhkan :

Mendeskripsikan transaksi

Menggunakan jalur transaksi

1.9Meninjau model data konseptual dengan pengguna

Bertujuan mengecek ulang model data konseptual dengan pengguna

untuk memastikan apa yang mereka pikirkan menjadi representasi nyata

dari data yang dibutuhkan oleh pengguna.

Gambar 2.3 Perancangan basis data konseptual

(Sumber : Connoly dan Begg, 2010, p480)

2.3.4

Perancangan Basis Data Logikal

Proses membangun data model yang digunakan dalam suatu

perusahaan berdasarkan pada model data yang spesifik

tetapi tidak

bergantung pada suatu DBMS tertentu dan pertimbangan fisik lainnya.

(Connolly dan Begg, 2010, p322)

Tujuan dari perancangan basis data logikal adalah untuk

menerjemahkan model data konseptual ke

dalam model data logikal

kemudian memvalidasi model tersebut untuk mengecek struktur yang benar

dan mampu mendukung transaksi yang dibutuhkan. Perancangan basis data

konseptual terdiri dari langkah – langkah berikut ini :

Langkah 2 : Membangun model data logikal

2.1Menurunkan hubungan untuk model data logikal

Bertujuan membuat hubungan

model data logikal untuk

merepresentasikan entitas, hubungan, dan atribut yang telah

diidentifikasi.

Menjelaskan bagaimana hubungan dapat diturunkan dari

struktur model yang ada sekarang, antara lain :

Tipe strong entity

Tipe weak entity

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 types

Many – to – many (*:*) binary relationship types

Complex relationship types

Multi – valued attributes

2.2Memvalidasi hubungan dengan menggunakan normalisasi

Bertujuan untuk memvalidasi hubungan di dalam model data

logikal dengan menggunakan normalisasi.

2.3Memvalidasi hubungan terhadap transaksi pengguna

Bertujuan untuk memastikan hubungan di dalam model data logikal

mendukung transaksi yang dibutuhkan.

2.4Memeriksa integrity constraints

Bertujuan untuk memeriksa apakah integrity constraints

direpresentasikan di dalam model data logikal. Berikut ini jenis integrity

constraints :

Data yang dibutuhkan

Attribute domain constraints

Multiplicity

Entity integrity

Referential integrity

General constraint

2.5Meninjau model data logikal dengan pengguna

Bertujuan untuk memeriksa kembali model data logikal dengan

pengguna untuk memastikan model yang mereka pertimbangkan menjadi

representasi nyata dari data yang dibutuhkan oleh pengguna.

2.6Menggabungkan model data logikal ke dalam model data global

(optional step)

Bertujuan untuk menggabungkan model data logikal lokal ke dalam

satu model data logikal global yang merepresentasikan semua pandangan

pengguna database.

2.7Memeriksa pertumbuhan yang akan datang

Bertujuan untuk menentukan apakah ada kemungkinan perubahan

yang signifikan di masa mendatang dan untuk menilai apakah model data

logikal dapat mengakomodasi perubahan.

Gambar 2.4 Perancangan basis data logikal

(Sumber : Connoly dan Begg, 2010, p516)

2.3.5

Perancangan Basis Data Fisikal

Proses menghasilkan deskripsi dari implementasi database

pada

penyimpanan sekunder, menggambarkan hubungan dasar, file organisasi,

dan indeks yang digunakan untuk mencapai akses yang efisien terhadap data,

dan setiap kendala integritas terkait dan tindakan keamanan. (Connolly dan

Begg, 2010, p322) Langkah dari metodologi perancangan basis data fisikal

adalah sebagai berikut :

Langkah 3 : Menerjemahkan model data logikal untuk sasaran DBMS

Ada tiga aktifitas dari langkah 3 ini, seperti :

Merancang base relation

Merancang representasi dari data turunan (derived data)

Merancang general constraint

3.1Merancang base relation

Bertujuan untuk memutuskan bagaimana merepresentasikan

hubungan dasar

yang

diidentifikasi pada model data logikal dalam

sasaran DBMS.

PropertyNumber:

Gambar 2.5 Contoh perancangan basis data fisikal base relation

(Sumber : Connoly dan Begg, 2010, p526)

Domain PropertyNumber:

variable length character string, length 3

Domain Street:

variable length character string, length 25

Domain City:

variable length character string, length 15

Domain Postcode :

variable length character string, length 8

Domain PropertyType:

single character, must be one of ‘B’, ‘C’, ‘D’, ‘E’,

‘F’, ‘H’, ‘M’, ‘S’

Domain PropertyRooms:

integer, in range 1 – 15

Domain PropertyRent:

monetary value, in the range 0.00 – 9999.99

Domain OwnerNumber:

variable length character string, length 5

Domain StaffNumber:

variable length character string, length 5

Domain BranchNumber:

variable length character string, length 4

PropertyForRent(

propertyNo

PropertyNumber

NOT NULL,

street

Street

NOT NULL,

city

City

NOT NULL,

postcode

Postcode,

type

PropertyType

NOT NULL DEFAULT ‘F’,

rooms

PropertyRooms

NOT NULL DEFAULT 4,

rent

PropertyRent

NOT NULL DEFAULT 600,

ownerNo

OwnerNumber

NOT NULL,

staffNo

StaffNumber,

branchNo

BranchNumber

NOT NULL,

PRIMARY KEY (propertyNo),

FOREIGN KEY (staffNo) REFERENCES Staff (staffNo) ON

UPDATE CASCADE ON DELETE SET NULL,

FOREIGN KEY (ownerNo) REFERENCES PrivateOwner(ownerfNo)

and BusinessOwner(ownerNo) ON UPDATE CASCADE ON DELETE

NO ACTION,

FOREIGN KEY (branchNo) REFERENCES Branch (branchNo) ON

UPDATE CASCADE ON DELETE NO ACTION);

3.2Merancang representasi dari data turunan (derived data)

Bertujuan untuk memutuskan bagaimana merepresentasikan setiap

derived data yang diperoleh mewakili model data logikal dalam DBMS

yang akan digunakan.

3.3Merancang general constraint

Merancang constraint tergantung pada pilihan DBMS, beberapa

sistem menyediakan fasilitas lebih daripada yang lain dalam

mendefinisikan general constraint.

Langkah 4 : Merancang file organizations dan indexes

Aktifitas yang ada pada langkah 4 adalah sebagai berikut :

Analisis transaksi

Memilih file organizations

Memilih indexes

Memperhitungkan kebutuhan disk space

4.1Analisis transaksi

Bertujuan untuk memahami fungsi dari transaksi yang akan

dijalankan di database dan untuk menganalisis transaksi penting.

4.2Memilih file organizations

Bertujuan untuk menentukan file organization

yang efisien untuk

setiap base relation.

4.3Memilih indexes

Bertujuan untuk menentukan apakah penambahan indeks akan

meningkatkan performa sistem.

4.4Memperhitungkan kebutuhan disk space

Bertujuan untuk menentukan jumlah dari disk space

yang

dibutuhkan untuk mendukung implementasi database dalam secondary

storage.

Langkah 5 : Merancang user views

Bertujuan untuk merancang user views yang telah diidentifikasi selama

pengumpulan kebutuhan dan dalam tahap analisis dari database system

development lifecycle.

Langkah 6 : Merancang security mechanisms

Bertujuan merancang mekanisme keamanan untuk database yang

dispesifikasikan oleh pengguna selama tahap requirement and collection

dari database system development lifecycle.

2.4 Perancangan Web Database

Web

adalah sebuah aplikasi internet. Web

menyediakan sebuah cara yang

mudah untuk mengakses informasi dan menjalankan program –

program yang

disimpan pada komputer yang dihubungkan oleh internet. (Eaglestone dan Ridley,

2001, p24)

Web

database system

adalah sistem dimana teknologi web

dan database

digunakan secara bersamaan. Web Database system menyediakan akses yang lebih

luas ke dalam sistem database dan meningkatkan kegunaan web. (Eaglestone dan

Ridley , 2001, p38)

Metode

web database design

merupakan sebuah

rangkaian

pada

model

–

model

yang

menggambarkan

penyimpanan

data

dalam

halaman – halaman

web,

dengan tambahan untuk data pada database. (Eaglestone dan Ridley, 2001, p263)

Sebagai basis data, struktur pada sebuah basis data web dapat mewakili level – level

berbeda

pada abstraksi, bersamaan

dengan

model

konseptual,

logikal, dan

fisikal

pada sistem basis data konvensional:

Conceptual Web Data Model

Conceptual web data model harus memperlihatkan struktur dari informasi yang

digambarkan oleh halaman – halaman web.

Logical Web Data Model

Logical

web

data

model

harus

memperlihatkan

bagaimana

struktur

–

struktur konseptual digambarkan dalam halaman web.

Physical Web Data Model

Physical web data model harus memperlihatkan bagaimana model logikal pada

halaman – halaman web diimplementasikan.

Menurut Eaglestone dan Ridley (2001,p264), web

database design

digambarkan sebagai berikut :

2.4.1

Web Data Analysis

Menurut

Eaglestone dan Ridley

(2001,

p284),

web

data

analysis

mendapatkan

sebuah

conceptual data model untuk

digambarkan

dengan

halaman

web.

Input

untuk

proses

ini adalah decription of the organization

and system requirements dan conceptual data model.

Tujuan dari web data analysis adalah sebagai berikut :

Membuat

peta

antara

informasi

yang

memperkenalkan

halaman

–

halaman web dan yang disimpan dalam basis data

Gambar 2.6 Diagram web database lifecycle

(Sumber : Eaglestone dan Ridley, 2001, p290)

Pengecekan validasi pada basis data

Model

konseptual

pada

halaman

–

halaman

web

memberikan

sebuah

basis

untuk membuktikan detail design dan implementasi pada halaman

–

halaman web adalah benar

Menjelang

masalah

perancangan,

hindari technical complexities,

seperti perancangan

dan implementasi

A. Web Data Extraction

Menurut Eaglestone dan Ridley

(2001, p289), Tujuan yang

pertama dari dua tahapan web data analysis adalah untuk menetapkan

Gambar 2.7 Web data analysis

(Sumber : Eaglestone dan Ridley, 2001, p290)

bagian model

konseptual

pada

database yang berhubungan

dengan

aplikasi

web database. Aturan kelengkapan yang harus diaplikasikan

adalah :

Kelengkapan atribut entitas

Kelengkapan identifikasi entitas

Kelengkapan referential

B. Web Database ER Model

Menurut

Eaglestone dan Ridley

(2001,

p285),

sebuah

web

database

mendukung aplikasi

–

aplikasi

database

melalui

interaksi

lewat halaman web.

Ketika

merancang

isi

data

dari

halaman web

sangat

penting

untuk menunjukan

sebuah

halaman

web

berbeda

dengan sebuah

tabel

relasi. Maka

dari

itu,

fitur

–

fitur

baru

harus

diikutsertakan

dalam

sebuah

model konseptual pada halaman-halaman web. Khususnya, ada

dua

aspek

pada halaman

–

halaman web

yang memerlukan perluasan

untuk model ER :

Hypermedia links

Hypermedia dibuat

oleh

halaman

web

dengan

tegas

menyediakan arah jalan navigasi antara entitas yang berhubungan.

Web application - specific concepts

Halaman – halaman

itu sendiri mewakili konsep – konsep yang

sangat penting untuk user. Dalam kasus lain, konsep – konsep yang

tidak

cocok

untuk

abstraction

dalam model

konseptual

database

masih harus diwakili dalam

model konseptual untuk

halaman web.

Digambarkan

dengan

bentuk

oval,

yang

disebut kotak konsep

(concept boxes).

C. Web Database Connectivity Analysis

Menurut Eaglestone dan Ridley

(2001, p293), tugas web

database connectivity analysis adalah

untuk

menganalisis

penjelasan

aplikasi basis data web agar

mengenali akses point sampai sistem, dan

arah jalur navigasi antara dan dengan halaman web.

Gambar 2.8 Conceptual (ER) model hypermedia

(Sumber : Eaglestone dan Ridley, 2001, p287)

2.4.2

Perancangan Web Data Logikal

Menurut

Eaglestone dan Ridley

(2001,

p310),

membahas

proses

dimana

struktur

–

struktur

data

dari

halaman

web

ditentukan.

Proses

mengambil

input

web conceptual model

dan menetapkan sebuah skema

untuk tiap halaman web.

A. Logical Web Page Schema

Menurut

Eaglestone dan Ridley

(2001,

p310),

halaman

web

menyediakan

akses

sumber web

dengan

menampilkan

informasi,

serta mengijinkan user berinteraksi dengan halaman. Halaman web dapat

rumit, baik yang ditampilkan maupun proses yang berkaitan.

Karakteristik

pada

halaman

–

halaman

web

memerlukan

beberapa

ciri

tambahan yang dimasukan ke bahasa skema logikal

konvensional. Khususnya kita harus dapat menetapkan :

Struktur – struktur pada halaman unik

Struktur – struktur umum ke banyak halaman

Links

Struktur – struktur data kompleks

Gambar 2.9 Logical Web Page Schema Untuk Rawat Jalan

(Sumber : Eaglestone dan Ridley, 2001, p317)

2.4.3

Perancangan Web Data Fisikal

Perancangan web data fisikal adalah desain bagaimana halaman web

yang akan diimplementasikan terhubung ke database. Menurut Eaglestone

dan Ridley (2001, p328), perancangan basis data fisikal adalah fase dalam

proses

perancangan dimana

perancang

memutuskan

bagaimana

basis data

disimpan.

Sebuah

DBMS

biasanya

akan

mendukung

sejumlah

alternatif

representasi fisikal pada struktur data logikal dan perancang harus memilih

yang paling tepat. Untuk itu perancang mengerti keuntungan dan hukuman

yang terhubung dengan tiap alternatif.

Tujuan

perancang

adalah

untuk

memilih

representasi

fisikal

untuk

tiap

struktur logikal seperti database

yang memiliki properti sebagai berikut :

Data boleh diakses dengan kecepatan yang pantas

Database

tidak dapat digunakan terlalu sering pada komputer

penyimpanan

“The

database

reasonably

resilient

catastrophes”.

Selalu

ada

kemungkinan untuk

memperbaiki

kerusakan

sistem

database,

dan

jika

bagian

pada

sistem gagal masih mungkin untuk remainder (sisa) di

“limp”.

Keputusan

perancangan

fisikal

harus

berdasarkan

pada

pengetahuan sebagai berikut :

Perancangan basis data fisikal

Perancang

harus mengetahui struktur mana yang termasuk dalam basis

data. Faktanya ini dapat ditentukan bahwa perancangan logikal harus

diganti sebagai favour certain applications.

Quantities dan volatility pada data

Perancang harus mengetahui jumlah data yang mungkin terjadi pada tiap

tabel atau kelas,

frekuensi

dimana

semuanya

akan

dirubah,

dan

biaya

dimana

tiap

tabel atau

kelas

akan

berkembang.

Pengetahuan

ini

juga

perlu untuk memilih struktur – struktur file yang paling tepat dan akses

metode – metode.

Cara penggunaan data

Idealnya, perancang harus mengetahui setiap aplikasi basis data :

Frekuensi aplikasi akan digunakan

Kedudukannya dibandingkan dengan aplikasi yang lain untuk

mengetahui kepentingan yang relatif

Waktu terlama yang dapat diterima untuk menjalankan aplikasi

Transaction properties

Juga untuk setiap transaksi dimana dapat terjadi selama aplikasi,

perancang harus mengetahui :

Sejumlah waktu transaksi dihasilkan ketika aplikasi dijalankan

Tabel -

tabel

dan

kolom –

kolom,

atau

kelas

–

kelas,

diakses

oleh

transaksi, dan tipe akses, contohnya retrieval, update, delete

atau insert

aktu terlama yang dapat diterima untuk menjalankan transaksi

Biaya

yang

dikelompokan

sesuai

penyimpanan

dan

pengaksesan

data,

diberikan tiap representasi yang ada pada relasi

–

relasi

atau kelas –

kelas.

Aplikasi web

dapat dibangun dalam client server architecture.

Client/server system adalah solusi komputasi terdistribusi dimana

representasi, logika presentasi, logika aplikasi, manipulasi data, dan lapisan

data yang didistribusikan antara

klien

dengan

satu atau lebih server.

(Whitten dan Bentley, 2007, p487)

Menurut Whitten dan Bentley (2007, p489), sistem

distributed data

client/server

merupakan solusi dimana data dan lapisan manipulasi data

ditempatkan pada server, dan logika aplikasi, logika presentasi, dan

presentasi ditempatkan pada klien. Ini disebut juga komputasi two-tiered

client/server.

Penting untuk memahami perbedaan antara sistem file server

dan

sistem distributed data client/server. Keduanya menyimpan database

nya

pada server. Tapi hanya sistem client/server

yang menjalankan semua

perintah manipulasi data pada server. Dalam sistem file server, perintah

manipulasi data harus diimplementasikan pada klien. Distributed data

client/server menawarkan beberapa keunggulan dibandingkan file server :

Terdapat lebih sedikit trafik jaringan karena hanya permintaan database

dan catatan database

yang dibutuhkan

dipindahkan ke dan dari

workstation klien.

Integritas database lebih mudah dalam perawatan. Hanya catatan yang

digunakan oleh klien yang biasanya harus dikunci. Klien lain secara

bersamaan dapat bekerja pada catatan lain dalam tabel atau database

yang sama.

Potensial kerugian untuk two-tiered client/server adalah bahwa logika

aplikasi harus digandakan dan dirawat pada semua klien, mungkin ratusan

atau ribuan. Perancang harus merencanakan upgrade versi dan menyediakan

kontrol untuk memastikan bahwa setiap klien menjalankan versi terbaru dari

logika bisnis, serta menghasilkan bahwa perangkat lunak lain di PC tidak

mengganggu logika bisnis.

Gambar 2.10 Two Tier Client Server Architecture

Sebuah

distributed data dan

application client/server system

merupakan solusi di mana (1) data dan lapisan manipulasi data ditempatkan

di server mereka sendiri, (2) logika aplikasi ditempatkan di server

sendiri,

dan

(3) hanya presentasi

logika dan presentasi ditempatkan pada klien. Ini

juga disebut three-tiered or n-tiered client/server computing.

Solusi three-tiered atau

n-tiered client/server

menggunakan

server

database yang sama

seperti pada pendekatan two-tiered. Selain itu, sistem

three-tiered

memperkenalkan aplikasi server atau transaksi server. Dengan

memindahkan

logika aplikasi ke servernya sendiri sehingga logika tersebut

hanya

perlu dirawat

server.

Dalam sistem three-tiered, klien

mengeksekusi sedikit dari komponen sistem secara keseluruhan. Hanya user

interface

dan beberapa

aplikasi

yang relatif

stabil atau

aplikasi logika

personal yang perlu dijalankan pada klien. Ini menyederhanakan konfigurasi

klien

dan manajemen.

Kelemahan terbesar

dari three-tiered

client/server

adalah kompleksitas

dalam desain

dan pengembangan. Aspek

tersulit

dari

desain aplikasi three-tiered client/server adalah partisi.

Gambar 2.11 Three Tier Client Server Architecture