bab 2 - library.binus.ac.idlibrary.binus.ac.id/ecolls/ethesisdoc/bab2/2012-1-01226-if...

8

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)

9

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.

10

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

11

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)

12

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

13

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

14

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.

15

•••• 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

16

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.

17

•••• 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.

18

Gambar 2.2 Entity Relationship (ER) diagram


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

19

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

deletion, dan modification anomalies.

Tabel 2.2 StaffBranch Relation


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.

20

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

21

• Partial dependency

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)

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

staffNo sName, Position, salary, branchNo, bAddress

branchNo bAddress

22

Tabel 2.3 ClientRental Unnormalized Table


clientNo

cName propertyNo

pAddress rentStart rentFinish rent ownerNo

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-07

350 CO40 Tina Murphy

PG36 2 Manor Rd, Glasglow

10-Oct-07

1-Dec-08 375 CO93 Tony Shaw


1-Nov-09

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


clienNo cName CR76 John Kay CR56 Aline Stewart

23

Tabel 2.5 1NF PropertyRentalOwner


clientNo

propertyNo

pAddress rentStart rentFinish rent ownerNo

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-07

350 CO40 Tina Murphy

CR56 PG36 2 Manor Rd, Glasglow

10-Oct-07

1-Dec-08 375 CO93 Tony Shaw

CR56 PG16 5 Novar Dr, Glasglow

1-Nov-09

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.

24

Tabel 2.6 2NF Client


clienNo cName CR76 John Kay CR56 Aline Stewart

Tabel 2.7 2NF Rental


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


propertyNo pAddress rent ownerNo oName PG4 6 Lawrence St,

Glasglow 350 CO40 Tina

Murphy PG16 5 Novar Dr,

Glasglow 450 CO93 Tony Shaw


375 CO93 Tony Shaw

Relasi yang didapat adalah sebagai berikut :


Rental (clientNo, propertyNo, rentStart, rentFinish)

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

I. 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.

25

(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


propertyNo pAddress rent ownerNo PG4 6 Lawrence St,

Glasglow 350 CO40


450 CO93


375 CO93

Tabel 2.10 3NF Owner


ownerNo oName CO40 Tina

Murphy CO93 Tony Shaw CO93 Tony Shaw

Hasil dari relasi 3NF adalah sebagai berikut :


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)

26

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.1 Mengidentifikasi 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.2 Mengidentifikasi 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.3 Mengidentifikasi 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.4 Menentukan domain atribut

Bertujuan menentukan domain untuk atribut dalam model data

konseptual. Domain atribut adalah himpunan nilai yang diijinkan untuk

satu atau lebih atribut.

27

1.5 Menentukan 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.6 Mempertimbangkan penggunaan enhanced modelling concepts

(optional step)

Bertujuan untuk mempertimbangkan penggunaan dari enhanced

modelling concepts, seperti specialization/generalization, aggregation,

dan composition.

1.7 Memeriksa model terhadap redundancy

Bertujuan untuk mengecek adanya redundancy pada sebuah model.

1.8 Memvalidasikan 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 :

a. Mendeskripsikan transaksi

b. Menggunakan jalur transaksi

1.9 Meninjau 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.

28

ownerNo

PrivateOwner

propertyNo

PropertyForRent

POwns

1..*

0..1

ownerNo

BusinessOwner

BOwns

1..*

0..1

clientNo

Client

Preference

leaseNo

Lease

Holds

1..1 1..1

0..* 1..1

AssociatedWith

0..*

1..1

States

Views

0..* 0..*

viewDate

comment

staffNo

Staff

Supervises

0..10..10

Supervisee

Registers

1..1

0..*

Managees

0..1

0..100

Gambar 2.3 Perancangan basis data konseptual


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

29

dan mampu mendukung transaksi yang dibutuhkan. Perancangan basis data

konseptual terdiri dari langkah – langkah berikut ini :

Langkah 2 : Membangun model data logikal

2.1 Menurunkan 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 :

a. Tipe strong entity

b. Tipe weak entity

c. One – to – many (1:*) binary relationship types

d. One – to – one (1:1) binary relationship types

e. One – to – one (1:1) recursive relationship types

f. Superclass / subclass relationship types

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

h. Complex relationship types

i. Multi – valued attributes

2.2 Memvalidasi hubungan dengan menggunakan normalisasi

Bertujuan untuk memvalidasi hubungan di dalam model data

logikal dengan menggunakan normalisasi.

2.3 Memvalidasi hubungan terhadap transaksi pengguna

Bertujuan untuk memastikan hubungan di dalam model data logikal

mendukung transaksi yang dibutuhkan.

30

2.4 Memeriksa integrity constraints

Bertujuan untuk memeriksa apakah integrity constraints

direpresentasikan di dalam model data logikal. Berikut ini jenis integrity

constraints :

a. Data yang dibutuhkan

b. Attribute domain constraints

c. Multiplicity

d. Entity integrity

e. Referential integrity

f. General constraint

2.5 Meninjau 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.6 Menggabungkan 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.7 Memeriksa 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.

31

Gambar 2.4 Perancangan basis data logikal


32

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.1 Merancang base relation

Bertujuan untuk memutuskan bagaimana merepresentasikan

hubungan dasar yang diidentifikasi pada model data logikal dalam

sasaran DBMS.

33

Gambar 2.5 Contoh perancangan basis data fisikal base relation


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);

34

3.2 Merancang 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.3 Merancang 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.1 Analisis transaksi

Bertujuan untuk memahami fungsi dari transaksi yang akan

dijalankan di database dan untuk menganalisis transaksi penting.

4.2 Memilih file organizations

Bertujuan untuk menentukan file organization yang efisien untuk

setiap base relation.

35

4.3 Memilih indexes

Bertujuan untuk menentukan apakah penambahan indeks akan

meningkatkan performa sistem.

4.4 Memperhitungkan 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)

36

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:

a. Conceptual Web Data Model

Conceptual web data model harus memperlihatkan struktur dari informasi yang

digambarkan oleh halaman – halaman web.

b. Logical Web Data Model

Logical web data model harus memperlihatkan bagaimana struktur –

struktur konseptual digambarkan dalam halaman web.

c. Physical Web Data Model

Physical web data model harus memperlihatkan bagaimana model logikal pada

halaman – halaman web diimplementasikan.

37

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 :

1. 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)

38

2. Pengecekan validasi pada basis data

3. Model konseptual pada halaman – halaman web memberikan sebuah

basis untuk membuktikan detail design dan implementasi pada halaman

– halaman web adalah benar

4. 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


39

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

40

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


41

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 ke 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

42

Gambar 2.9 Logical Web Page Schema Untuk Rawat Jalan


43

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 :

a. Data boleh diakses dengan kecepatan yang pantas

b. Database tidak dapat digunakan terlalu sering pada komputer

penyimpanan

c. “The database is reasonably resilient to 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 :

a. 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.

44

b. 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.

c. 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

d. 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

- W

aktu terlama yang dapat diterima untuk menjalankan transaksi

e. Biaya yang dikelompokan sesuai penyimpanan dan pengaksesan data,

diberikan tiap representasi yang ada pada relasi – relasi atau kelas –

kelas.

45

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 PC 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 :

a. Terdapat lebih sedikit trafik jaringan karena hanya permintaan database

dan catatan database yang dibutuhkan dipindahkan ke dan dari

workstation klien.

b. 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.

46

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

47

three-tiered memperkenalkan aplikasi server atau transaksi server. Dengan

memindahkan logika aplikasi ke servernya sendiri sehingga logika tersebut

hanya perlu dirawat di 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

bab 2 - library.binus.ac.idlibrary.binus.ac.id/ecolls/ethesisdoc/bab2/2012-1-01226-if...

Documents