BAB 2

LANDASAN TEORI

2.1

Teori-Teori Umum
Dalam penyusunan skripsi ini ada beberapa teori umum yang digunakan sebagai

landasan. Di bawah ini adalah pemaparan teori-teori tersebut.

2.1.1

Teori-Teori Database
2.1.1.1 Basis Data
Menurut Connolly (2010, p65), basis data adalah suatu koleksi bersama
data-data yang saling terkait secara logis, dan juga merupakan pendeskripsian
dari data-data tersebut, yang dirancang untuk menyajikan informasi yang
dibutuhkan oleh sebuah organisasi.
Database juga dapat diartikan sebagai serangkaian program komputer
yang mengendalikan pembuatan, pemeliharaan, dan pemanfaatan basis data
sebagai sebuah organisasi (OBrien, 2003, p5).
Dalam basis data, terdapat tiga istilah penting, yakni entitas, atribut, dan
relationship. Entitas adalah sebuah objek berbeda (bisa seseorang, tempat,
sesuatu,

konsep,

ataupun

kejadian)

dalam

organisasi

yang

harus

direpresentasikan dalam basis data. Atribut adalah sebuah properti yang

mendeskripsikan beberapa aspek dari objek yang ingin di-record. Relationship
adalah asosiasi antar entitas (Connolly, 2010, p65).

2.1.1.2 Konsep Model ERD

Relationship
Relationship adalah Kumpulan keterhubungan yang mempunyai arti
(meaningful

associations)

antara

type

entitas

yang

ada

(Connolly,2010,p374).

Gambar 2. 1 Relationship Branch has Staff

(Connolly, Database Systems, p375)

Structural Constraints
Batasan utama pada relationship disebut multiplicity, yaitu jumlah
(atau range) darikejadian yang mungkin terjadi pada suatu entitas yang
terhubung ke satu kejadian dari entitaslain yang berhubungan melalui
suatu relationship. Relationship yang paling umum adalah binary
relationship. Macam-macam binary relationship yaitu :

 one-to-one (1:1)

Gambar 2. 2 ER Diagram of Staff and Branch Entities and general constraint

(Connolly, Database Systems, p382)

one-to-many(1:*)

Gambar 2. 3 ER Diagram of Staff and PropertyForRent Entities and general

constraint
(Connolly, Database Systems, p388)

 many-to-many(*:*)

Gambar 2. 4 ER Diagram of Staff and PropertyForRent Entities and general

constraint
(Connolly, Database Systems, p389)
Attributes
Menurut Connolly(2010,p379) attributes merupakan sifat-sifat (property)
dari sebuah entitas atau tipe relationship. Attribute Domain adalah
himpunan nilai yang diperbolehkan untuk satu atau lebihatribut. Macammacam atribut :

Simple Attribute, yaitu atribut yang terdiri dari satu komponen

tunggal dengankeberadaan yang independen dan tidak dapat
dibagi menjadi bagian yang lebih kecillagi. Dikenal juga dengan
nama Atomic Attribute.

Composite Attribute, yaitu atribut yang terdiri dari beberapa

komponen,

dimana

masing-masing

komponen

memiliki

keberadaan yang independen. Misalkan atributAddress dapat

terdiri dari Street, City, PostCode.

Single-valued Attribute, yaitu atribut yang mempunyai nilai

tunggal untuk setiapkejadian. Misalnya entitas Branch memiliki
satu nilai untuk atribut branchNo padasetiap kejadian.

Multi-valued Attribute, yaitu atribut yang mempunyai beberapa

nilai untuk setiapkejadian. Misal entitas Branch memiliki
beberapa nilai untuk atribut telpNo pada setiapkejadian.

Derived Attribute, yaitu atribut yang memiliki nilai yang

dihasilkan dari satu ataubeberapa atribut lainnya dan tidak harus
berasal dari satu entitas.

Keys

Candidate Key, yaitu jumlah minimal atribut-atribut yang dapat

meng-identifikasikan setiap kejadian/record secara unik.

Primary

Key,

yaitu

Candidate

key

yang

dipilih

untuk

mengidentifikasikan setiapkejadian/record dari suatu entitas

secara unik.

Composite Key, yaitu Candidate key yang terdiri dari dua atau
lebih atribut.

Gambar 2. 5ER Diagram of Staff and Branch Entities and their Attributes
(Connolly, Database Systems, p382)

2.1.1.3 Normalisasi
Menurut Connolly (2010, p416) tujuan utama dalam pengembangan
model data logical pada sistem basis relasionaladalah untuk menciptakan
representasi akurat suatu data, keterhubungannya dan batasan-batasannya.Untuk
mencapai tujuan ini, maka harus ditetapkan/diidentifikasi sekumpulan relasi.
Empat bentuk normal yang biasa digunakan yaitu, first normal form (1NF),
second normalform (2NF) dan third normal form (3NF) dan BoyceCodd normal
form (BCNF).Terdapat bentuk fourth normal form (4NF) dan fifth normal form
(5NF) untuk situasi yangjarang terjadi.
Berdasarkan pada functional dependencies antar atribut dalam relasi.
Sebuah relasi dapat dinormalisasi kedalam bentuk tertentu untuk mengatasi
kemungkinanterjadinya pengulangan dari update yang tidak baik.Normalisasi
adalah suatu teknik untuk menghasilkan sekumpulan relasi dengan sifatsifat(properties) yang diinginkan, memenuhi kebutuhan data pada enterprise.
1. Data Redundacy

Menurut Connolly (2010, p418) tujuan utama dari desain basis data
relasional adalah untuk mengelompokkan atribut-atribut ke dalam relasirelasi sehingga meminimalisasi redundansi data dan mengurangi penggunaan
tempat penyimpanan yang dibutuhkan oleh sebuah relasi dasar.Masalahmasalah yang terkait dengan redundansi dapat dijelaskan dengan
membandingkanrelasi Staff dan Branch dengan relasi StaffBranch.Relasi
StaffBranch memiliki data redundan, yaitu detail dari branch dituliskan
berulang-ulanguntuk setiap staff.Sebaliknya, informasi mengenai branch
muncul hanya satu kali pada relasi Branch danhanya branchNo saja yang
diulang dalam relasi Staff, untuk merepresentasikan dimana setiap staff
tersebut bekerja.

Gambar 2. 6 Contoh Data Redundancy

(Connolly, Database Systems, p419)
2. Update Anomalies
Menurut Connolly (2010, p419) relasi yang mengandung informasi yang
redundan dapat diakibatkan oleh update anomalies. Beberapa tipe dari update
anomalies, diantaranya Insertion, Deletion, dan Modification.
3. Functional dependency

Menurut Connolly (2010, p420) merupakan konsep inti yang terkait dengan
normalisasi.Functional dependency, menjelaskan relationship antar atributatribut dalam relasi.Misalkan, jika A dan B adalah atribut dari suatu relasi R,
B dikatakan Functionally Dependent pada A (dinotasikan A --> B), jika setiap
nilai A dihubungkan dengan tepat satu nilai B. ( A dan B masing-masing
dapat terdiri atas satu atau lebih atribut). Functional dependency merupakan
sifat dari arti semantik suatu atribut dalam sebuah relasi. Direpresentasikan
dalam diagram :

Gambar 2. 7 Contoh Functional dependency

(Connolly, Database Systems, p420)
Determinant dari functional dependency mengacu kepada atribut atau
himpunan atributdisebelah kiri anak panah.

Gambar 2. 8Contoh Functional dependency

(Connolly, Database Systems, p419)

Aturan Functional Dependencies (Armstrongs Axioms) :

Reflectivity
Jika B adalah bagian dari A, maka A
B

Augmentation
Jika A
B, maka A,C
B,C

Transitivity
Jika A
B dan B
C, maka A
C

Decomposition
Jika A
B,C, maka A
B dan A
C

Union
Jika A
B dan A
C, maka A
B,C

Composition
Jika A
B dan C
D, maka A,C
B,D

2.1.2

Teori Perancangan Basis Data

2.1.2.1 Pendekatan Perancangan Basis Data
Menurut Connolly (2010, p321), database adalah kumpulan aplikasi yang
berinteraksi dengan basis data.
Terdapat berbagai pendekatan yang dapat digunakan dalam perancangan
basis data, yaitu :

1.

Top-down

Pendekatan ini diawali dengan pembentukan model data yang berisi beberapa
entitas high level dan relationship, kemudian entitas lower level, relationship,
dan atribut lainnya akan didefinisikan secara berurut ke bawah.
2.

Bottom-up

Pendekatan ini diawali dengan atribut-atribut dasar, yang terdiri dari sifat entitas
dan relationship, kemudian dilanjutkan dengan analisis dan penggabungan antar
atribut yang dikelompokkan di dalam suatu relasi yang menggambarkan tipe dari
entitas dan relationship antar entitas.
3.

Inside-out

Mirip dengan pendekatan bottom-up, namun identifikasi awal dimulai dengan

entitas utama, kemudian menyebar ke identifikasi entitas, relationship, dan
atribut lainnya yang masih terkait, yang sebelumnya telah diidentifikasi terlebih
dahulu.
4.

Mixed

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

sesuai dengan kecocokan, dan kemudian digabungkan.

2.1.2.2 Tahapan Perancangan Basis Data

Perancangan basis data terdiri dari tiga tahap utama, yaitu :
1. Perancangan basis data konseptual
Pada tahap ini, model data dibuat dari sudut pandang dunia nyata dan terlepas
dari pertimbangan fisik. Model desain hanya terdiri dari blok-blok dengan nama
tabel dan relasi yang terjadi antar-tabel.

2. Perancangan basis data logikal

Suatu proses pembentukan model dari informasi yang digunakan dalam
enterprise berdasarkan model data tertentu ( misal : relasional), tetapi independen
terhadap DBMS tertentu dan aspek fisik lainnya. Sumber data berasal dari ERD
Model pada perancangan basis data konseptual.
3. Perancangan basis data Fisikal
Suatu

proses

yang

menghasilkan

deskripsi

implementasi

basis

data

padapenyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode

aksesyang digunakan untuk mencapai akses yang efisien terhadap data. Dapat
dikatakanjuga, desain fisikal merupakan cara pembuatan menuju sistem DBMS
tertentu
Menurut Connolly dan Begg (2010,p320), perancangan basis data
merupakan suatu proses pembuatan sebuah desain database yang akan
mendukung tujuan dan operasi suatu enterprise.
Tujuan utamanya adalah :
Merepresentasikan data dan relationship antar data yang dibutuhkan oleh
seluruh area aplikasi utama dan user group.
Menyediakan model data yang mendukung segala transaksi yang diperlukan
pada data.
Menspesifikasikan desain minimal yang secara tepat disusun untuk memenuhi
kebutuhan performa yang ditetapkan pada sistem (misal : waktu respon).

Contoh kasus :
Kumpulan formulir-formulir penyewaan properti. Berikut dimasukkan ke dalam
tabel :
Tabel 2. 1 Contoh Tabel Kasus Untuk Penyewaan Properti
No.Penyewa
A

No.Properti
B

PE001

PR01
PR03
PR01
PR04

PE002

Sewa/bulan
G

Nama
Penyewa
C
Andri
Reni

Alamat
Properti
D
JL.Kebon
JL.Sawah
JL.Kebon
JL.Rawa

Tgl.Mulai
E

Tgl.Akhir
F

01/01/2009
01/01/2009
01/01/2008
01/01/2009

01/06/2009
01/12/2009
01/12/2008
01/06/2009

No.Pemilik
H

Nama
Pemilik
I
500
PE01
Michael
1000
PE03
Roni
PE01
500
Michael
PE04
1500
Tobi
Functional Dependencies yang terdapat pada relasi SewaProperti dari tabel kasus
penyewaan properti :
Fd1 No.Penyewa, No.Properti
Tgl.Mulai, Tgl.Akhir (Primary Key)
Fd2 No.Penyewa
NamaPenyewa (Partial Dependency)
Fd3 No.Properti
AlamatProperti, Sewa/bulan, No.Pemilik, NamaPemilik
(Partial Dependency)
Fd4 No.Pemilik
NamaPemilik (Transitive Dependency)

Gambar 2. 9 Analisis Functional dependency dari Penyewaan Properti

Pada Segmen 1 / 1NF :

A dan B adalah Primary Key.

Mencari relasi fully dependency, yaitu atribut non key yang tergantung
kepada seluruh atribut primary key.

A,B
E,F,G,H,I,C,D

Pada Segmen 2 / 2NF :

Mencari relasi partial dependency, yaitu atribut non key yang tergantung
kepada sebagian atribut primary key.

A,B
E,F
A dan B adalah Primary Key, sekaligus Foreign Key. Menjadi tabel
SewaProperti.
A
C,
A adalah Primary Key. Menjadi tabel Penyewa.
B
D,G,H ,I ,
B adalah Primary Key. Menjadi tabel Properti.

Pada Segmen 3 / 3NF :

Mencari relasi transitive dependency, yaitu atribut non key yang

tergantung kepada atribut bukan primary key.

A,B
E,F
A dan B adalah Primary Key, sekaligus Foreign Key. Menjadi tabel
SewaProperti.
A
C,
A adalah Primary Key. Menjadi tabel Penyewa.
B
D,G,H ;
B adalah Primary Key. H adalah Foreign Key. Menjadi tabel Properti.
H
I ;
H adalah Primary Key. Menjadi tabel pemilik.

Transaksi sistem yang dibutuhkan :

a. Menampilkan data penyewa yang meliputi No.Penyewa dan Nama Penyewa.
b. Menampilkan data pemilik yang meliputi No.Pemilik dan Nama Pemilik.

c. Menampilkan data SewaProperti berdasarkan Pemilik properti tertentu.

2.1.2.3 Perancangan Database Konseptual

Suatu proses pembentukan model dari informasi yang digunakan dalam
enterprise,independen dari keseluruhan aspek fisik. Model data dibangun dengan
menggunakan informasi dalam spesifikasi kebutuhan user. Model data
konseptual merupakan sumber informasi untuk fase desain logikal (Connolly
2010, p467).
Adapun langkah-langkahnya yaitu :
1. Identifikasi tipe entitas
Untuk mengidentifikasikan entitas utama yang dibutuhkan oleh view.
Mendefinisikan objekutama dimana user mempunyai ketertarikan dengan objek
tersebut. Objekini adalah tipe entitas untuk model. Salah satu metode untuk
mengidentifikasi entitas adalah dengan menguji spesifikasi kebutuhan dari user.
Dari spesifikasi ini kita mengidentifikasikan kata benda dan ungkapan kata
benda(nous phrases) yang disebutkan. Kita juga dapat melihat objek utama
seperti orang, tempat ataukonsep dari ketertarikan diluar kata benda lainnya yang
merupakan kualitas dari objek lain.
Berdasarkan contoh kasus di atas berikut adalah Tabel Kamus Tipe Entitas :
Tabel 2. 2 Tabel Kamus Entitias
Entitas Name

Description

Aliases

Occurance

Penyewa

Mendeskripsikan
semua Penyewa

Pelanggan

Setiap penyewa dapat

memiliki satu atau banyak
SewaProperti

Properti

Mendeskripsikan
semua properti

Rumah

Mendeskripsikan
semua pemilik
yang mempunyai
properti

Pemilik

Pemilik

Setiap pemilik memiliki

satu atau lebih bukti
SewaProperti

2. Identifikasi tipe relationship

Tujuannya untuk mengidentifikasikan relationship penting yang ada antara tipe
entitas yang telahdiidentifikasikan. Kita dapat menggunakan grammar dari
spesifikasi kebutuhan tersebut untuk mengidentifikasi relationship, biasanya
relationship dinyatakan oleh kata kerja/verb atau ekspresi verbal. Secara
langsung relationship tersebut adalah binary, dengan kata lain relationship
tersebut berada antara dua type entitas.
Berdasarkan contoh kasus di atas berikut adalah tabel kamus entitas
relationships:
Tabel 2. 3 Tabel Kamus Tipe Relasi
Entitas
Name
Penyewa
Pemilik

Multiplicity

Relationship

1..*
1..1

Memiliki
Memiliki

Entitas
Name
Properti
Properti

Multiplicity
1..*
1..*

3. Identifikasi dan Hubungkan Atribut dengan Entitas atau Tipe Hubungan

Tujuannya untuk menghubungkan atribut dengan entitas atau tipe relationship
yang sesuai dan mendokumentasikan detail dari setiap atribut. Atribut-atribut
bisa diidentifikasi dengan kata benda atau ungkapan kata benda (nouns phrases)
seperti property, kualitas, identifier atau karakteristik dari satu entitas atau
hubungan.

Berdasarkan contoh kasus di atas berikut adalah Tabel Kamus Hubungan Atribut
dengan Entitas :
Tabel 2. 4 Tabel Kamus Hubungan Atribut
Entitas
Name
Penyewa

Attributes

Description

No.Penyewa

Unik, mengidentifikasi
setiap penyewa
Nama Penyewa

NamaPenyewa
No.Properti

Properti

Alamat
Sewa/bulan
No.Pemilik

Pemilik
NamaPemilik

Unik, mengidentifikasi
setiap properti
Alamat properti
Harga sewa per bulan
Unik, mengidentifikasi
setiap pemilik
Nama Pemilik

Data type
& length

Nulls

Multivalued

10 varchar

No

30 varchar

No

10 varchar

No

No

50 varchar
15 varchar

No
No

No
No

10 varchar

No

No

35 varchar

No

No

No
No

4. Tetapkan domain atribut

Tujuannya untuk menetapkan domain atribut dalam model data konseptual lokal
dan mendokumentasikan setiap detail dari domain. Domain merupakan
sekumpulan (pool) nilai-nilai darisatu atau lebih atribut yang menggambarkan
nilainya.
Berdasarkan contoh kasus di atas berikut adalah tabel domain atributnya :
Tabel 2. 5 Domain Atribut
Entitas name
Penyewa
Properti
Pemilik

Attributes

Domain

No.Penyewa
NamaPenyewa
No.Properti
Alamat
Sewa/bulan
No.Pemilik
NamaPemilik

Di awali dengan PY

Di awali dengan PR
Di awali dengan PE

5.

Tetapkan Atribut Primary dan Candidate key

Untuk mengidentifikasikan candidate key untuk setiap entitas dan jika terdapat
lebih dari satucandidate key, maka pilih satu sebagai primary key.
Berdasarkan contoh kasus di atas berikut adalah tabel atribut primary dan
candidate key :
Tabel 2. 6 Tabel Atribut Primary Key dan Candidate Key

Penyewa(No.Penyewa,NamaPenyewa)
Candidate Key NamaPenyewa
Primary Key No.Penyewa
Alternate Key NamaPenyewa
Properti (No.Properti, Alamat, Sewa/bulan)
Candidate Key No.Properti
Primary Key No.Properti
Alternate Key
Pemilik(No.Pemilik, NamaPemilik)
Candidate Key No.Pemilik, NamaPemilik
Primary Key No.Pemilik
Alternate Key NamaPemilik

Gambar 2. 10 Gambar ER dengan Primary Key

6. Periksa Model Untuk Pengurangan
Dalam langkah ini kita menguji model data konseptual lokal dengan tujuan
spesifik untuk mengidentifikasikan apakah ada redundancy dalam data dan
memindahkan data yang telah ada. Dua aktifitas dalam langkah ini adalah:

Menguji ulang relationship 1-1 (one-to-one)

Berdasarkan contoh kasus di atas hubungan relationship 1-1 tidak ditemukan

selama proses analisis.

Menghilangkan relationship yang redundan

Berdasarkan contoh kasus di atas tidak ada redundanrelationship yang terjadi.

Dari 2 tahapan di atas, maka dapat disimpulkan bahwa tidak ada redudansi data
yang terjadi.
7. Validasi Model Konseptual Lokal Terhadap Transaksi User
Tujuannya untuk memastikan model konseptual lokal mendukung transaksi yang
dibutuhkanoleh view. Diuji dua pendekatan untuk memastikan model data
konseptual lokal mendukung transaksiyang dibutuhkan, dengan cara :
Mendeskripsikan transaksi-transaksi
Memeriksa seluruh informasi (entitas, relationship, dan atribut) yang dibutuhkan
oleh setiap transaksi telah disediakan oleh model, dengan mendokumentasikan
setiap kebutuhan transaksi.
Berdasarkan contoh kasus di atas deskripsi transaksinya meliputi :
a.

Menampilkan data penyewa yang meliputi No.Penyewa dan Nama

Penyewa.

b.

Menampilkan data pemilik yang meliputi No.Pemilik dan Nama Pemilik.

c.

Menampilkan data Properti berdasarkan Pemilik properti tertentu.

Mengunakan jalur-jalur transaksi

Untuk validasi model data terhadap transaksi yang dibutuhkan termasuk

representasi diagram jalur yang digunakan oleh setiap transaksi langsung pada
ER diagram.

Gambar 2. 11 Gambar ER dengan Jalur Transaksi

8. Review Model Data Konseptual Lokal Dengan User
Tujuannya untuk me-review model data konseptual lokal dengan user untuk
memastikan modeltersebut adalah representasi sebenarnya dari view. Model data
konseptual ini termasuk ER diagramdan dokumentasi pendukung yang
mendeskripsikan model data. Bila ada kejanggalan(anomali) dalam model data,
maka harus dibuat perubahan yang sesuai yang mungkin membutuhkan
pengulangan langkah-langkah sebelumnya.

2.1.2.4 Perancangan Database Logikal

Suatu proses pembentukan model dari informasi yang digunakan dalam
enterprise berdasarkan model data tertentu ( misal : relasional), tetapi independen
terhadap DBMS tertentu dan aspek fisik lainnya. Model data konseptual yang

telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logikal
(Connolly,2010, p490).
Adapun langkah-langkahnya yaitu :

1. Menghilangkan fitur yang tidak sesuai dengan model relasional

Menghilangkan hubungan many to many (*..*)
Pada ERD Konseptual terjadi hubungan entiti yang *..*. Hubungan ini harus
dihilangkan dengan menambah entiti baru.
Dari contoh kasus di atas terdapat hubungan many to many (*..*) yang terdapat
pada penyewa dengan properti. Cara mengatasinya dengan menciptakan Entiti
baru, yaitu SewaProperti.
Menghilangkan atribut yang multi-valued
Pada bagian identifikasi atribut ada beberapa entiti yang mempunyai atribut yang
multi-valued. Hal ini harus dihilangkan dengan memisahkan atribut yang multivalued dari entitinya. Biasanya multi-valued berupa atribut telepon.
Pada contoh kasus di atas tidak terdapat multi-valued.

Gambar 2. 12 Gambar ER dengan menghilangkan fitur yang tidak sesuai

2. Menurunkan relasi untuk Model Data Logikal

Tahapan ini membentuk relasi dari model data logikal untuk merepresentasikan
relasi antar entiti dengan atribut yang telah didefinisikan. Untuk mendapatkan
relasi dari data model yang ada, makan digunakan cara-cara berikut ini :
1. Strong entitas types;
2. Weak entitas types;
3. One-to-many (1:*) binary relationship types;
4. One-to-one (1:1) recursive relationship types;
5. One-to-one (1:1) binary relationship types;
6. Superclass/subclass relationship types;
7. Many-to-many (*:*) binary relationship types;
8. Complex relationship types;
Dari contoh kasus di atas hanya terdapat 4 tahapan yang perlu diturunkan, yaitu:
a. Strong Entitas

Pemilik(No.Pemilik, NamaPemilik)
Primary Key No.Pemilik
Properti(No.Properti, Alamat, Sewa/bulan)
Primary Key No.Properti
Penyewa(No.Penyewa, NamaPenyewa)
Primary Key No.Penyewa
b. Weak Entitas
SewaProperti(No.Penyewa, No.Properti, TglMulaiSewa, TglAkhirSewa)
Primary Key No.Penyewa, No.Properti

c. One to Many Relationship (1:*)

Masukkan No.Pemilik dalam Properti untuk model 1:* relasi memiliki

Pemilik(No.Pemilik, NamaPemilik)
Primary Key No.Pemilik

Properti(No.Properti,No.Pemilik,
Alamat, Sewa/bulan)
Primary Key No.Properti

d. Many to Many Relationship ( * : *)

Penyewa(No.Penyewa, NamaPenyewa)
Primary Key No.Penyewa

Properti(No.Properti,
Sewa/bulan)
Primary Key No.Properti

SewaProperti(No.Penyewa, No.Properti, TglMulaiSewa, TglAkhirSewa)

Primary Key No.Penyewa, No.Properti
Foreign Key No.Penyewa references Penyewa (No.Penyewa)

Alamat,

Gambar 2. 13 Menurunkan untuk Model Data Logikal

3. Memvalidasi relasi dengan normalisasi

Untuk merancang basis data yang baik, biasa dilakukan normalisasi. Normalisasi
merupakan sebuah teknik untuk menghasilkan set relasi dengan property yang
desirable dan memberikan data sesuai dengan kebutuhan enterprise.
Tujuan normalisasi yaitu:
mengidentifikasi hubungan antar atribut
mengkombinasikan atribut untuk membentuk relasi
mengkombinasikan relasi untuk membentuk database
menghindari anomali
UNF
Dalam proses normalisasi UNF kita menampilkan semua field atau atribut yang
ada dalam suatu form yang ingin kita normalisasi.

Berdasarkan contoh kasus di atas UNF yang terjadi sebagai berikut

SewaRumah

(No.Penyewa,

NamaPenyewa,{No.Properti,

AlamatProperti,

Tgl.MulaiSewa, Tgl.AkhirSewa, Sewa/bulan, No.Pemilik, NamaPemilik} )

1NF
Sebuah relasi berada dalam 1NF jika relasi tersebut tidak berisi atribut yang
berulang (repeating group), field hasil perhitungan dihilangkan dan sudah
mempunyai primary key.
Berdasarkan contoh kasus di atas terjadi
SewaRumah

(No.Penyewa,No.Properti,

NamaPenyewa,

AlamatProperti,

Tgl.MulaiSewa, Tgl.AkhirSewa, Sewa/bulan, No.Pemilik, NamaPemilik)

2NF
Sebuah relasi berada dalam 2NF jika relasi tersebut dalam 1NF dan untuk setiap
atribut non key bergantung fungsional penuh kepada primary key. Jadi pada 2NF
kita akan menghilangkan ketergantungan sebagian / partial : ketergantungan
field-field tertentu hanya kepada salah satu key yang composite.
Berdasarkan contoh kasus di atas terjadi
Penyewa (No.Penyewa, NamaPenyewa)
SewaRumah (No.Penyewa,No.Properti, TglMulaiSewa, TglAkhirSewa)
Properti_Pemilik(No.Properti,
NamaPemilik)

AlamatProperti,

Sewa/bulan,

No.Pemilik,

3NF
Sebuah relasi berada dalam 3NF bila relasi tersebut dalam 1NF dan 2NF dan
tidak ada atribut non-key yang tergantung fungsional kepada atribut non-key yang
lainnya (transitive dependency).
Berdasarkan contoh kasus di atas terjadi
Penyewa(No.Penyewa, NamaPenyewa)
SewaRumah(No.Penyewa,No.Properti, TglMulaiSewa, TglAkhirSewa)
Properti (No.Properti, AlamatProperti, Sewa/bulan, No.Pemilik)
Pemilik(No.Pemilik, NamaPemilik)

Gambar 2. 14 Diagram Model Relasional

4. Memeriksa Integrity Constraints

Integrity constraints adalah batasan-batasan yang harus ditentukan untuk
melindungi basis data agar tetap konsisten.

Tabel 2. 7 Tabel Integrity Constraints

Pemilik(No.Pemilik, NamaPemilik)
Primary Key No.Pemilik
Penyewa (No.Penyewa, NamaPenyewa)
Primary Key No.Penyewa
Properti(No.Properti, No.Pemilik, AlamatProperti, Sewa/bulan)
Primary Key No.Properti
Foreign Key No.Pemilik referencesPemilik (No.Pemilik) ON
UPDATE CASCADE ON DELETE NO ACTION
SewaProperti(No.Properti,
No.Penyewa,
Tgl.MulaiSewa,
Tgl.AkhirSewa)
Primary Key No.Properti, No.Penyewa
Foreign Key No.Properti referencesProperti (No.Properti) ON
UPDATE CASCADE ON DELETE NO ACTION
Foreign Key No.Penyewa referencesPenyewa (No.Penyewa) ON
UPDATE CASCADE ON DELETE NO ACTION

5. Review Model Data Logikal Dengan User

Review logical data model dengan pengguna dilakukan untuk memastikan bahwa
model yang telah dibuat sudah benar atau sesuai dengan kebutuhan pengguna.
Dari hasil review dengan pengguna, model data logikal yang dihasilkan sudah
sesuai dengan kebutuhan yang ada. Sehingga, sudah dapat dilanjutkan ke tahap
selanjutnya.
6. Memeriksa Untuk Pertumbuhan di Masa Depan
Model data logikal yang dirancang sudah disesuaikan dengan kemungkinan yang
mungkin terjadi di masa depan, kecuali jika terjadi perubahan pada kebutuhan
pengguna.

2.1.2.4 Perancangan Database Fisikal

Suatu proses yang menghasilkan deskripsi implementasi basis data
padapenyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode
aksesyang digunakan untuk mencapai akses yang efisien terhadap data. Dapat
dikatakan juga, desain fisikal merupakan cara pembuatan menuju sistem DBMS
tertentu (Connolly, 2010, p522).
Adapun langkah-langkahnya yaitu :
1.

Merancang relasi dasar

Dalam merancang relasi dasar digunakan DBDL (Database Design Language)

untuk mendeskripsikan definisi relasi. Untuk setiap relasi diberikan deskripsi
yang meliputi nama relasi, atribut, primary key, alternate key, foreign key, atribut
yang merupakan hasil perhitungan, referential integrity, domain dan apakah
atribut boleh NULL.
Pada contoh kasus di atas berikut ini merupakan DBDL dari relasi yang ada :
Pemilik
Domain

No.Pemilik
: variable length character
string, length 10,diawali dengan
PE
Domain NamaPemilik : variable length character string,
length 35
Pemilik(
No.Pemilik
Nomor Pemilik
NamaPemilik
Nama Pemilik
Primary Key (No.Pemilik));

Penyewa
Domain No.Penyewa

NOT NULL,
NOT NULL,

:
variable
length
character
string, length 10,diawali dengan PY
Domain NamaPenyewa
:
variable length character
string, length 30

Penyewa(
No.Penyewa
Nomor Penyewa
NamaPenyewa
Nama Penyewa
Primary Key (No.Penyewa));

NOT NULL,
NOT NULL,

Properti
Domain No.Properti :
variable
length
character
string, length 10,diawali dengan PR
Domain Alamat : variable length character string,
length 50
Domain Sewa/bulan
: integer value
Domain No.Pemilik
:
variable
length
character
string, length 10,diawali dengan PE
Properti (
No.Properti
Nomor Properti
NOT NULL,
AlamatProperti Alamat Properti
NOT NULL,
Sewa/bulan
Sewa per Bulan
NOT NULL,
No.Pemilik
Nomor Pemilik
NOT NULL,
Primary Key (No.Properti),
Foreign
Key
(No.Pemilik)
references
Pemilik
(No.Pemilik) ON UPDATE CASCADE ON DELETE NO ACTION );

SewaProperti
Domain No.Properti
: variable length character
string, length 10,diawali dengan PR
Domain No.Penyewa : variable length character string,
length 10,diawali dengan PY
Domain Tgl.MulaiSewa : date/time
Damain Tgl.AkhirSewa : date/time
SewaProperti(
No.Properti
Nomor Properti
NOT NULL,
No.Penyewa
Nomor Penyewa
NOT NULL,
Tgl.MulaiSewa Tanggal Mulai Sewa NOT NULL,
Tgl.AkhirSewa Tanggal Akhir Sewa NOT NULL,
Primary Key (No.Properti, No.Penyewa),
Foreign
Key
(No.Properti)
references
Properti
(No.Properti) ON UPDATE CASCADE ON DELETE NO ACTION,
Foreign
Key
(No.Penyewa)
references
Penyewa
(No.Penyewa) ON UPDATE CASCADE ON DELETE NO ACTION );

2.

Menganalisis transaksi

Tujuan dari langkah ini adalah untuk memahami fungsionalitas dari transaksi
yang akan berjalan pada basis data dan untuk menganalisis transaksi yang
penting.
Berdasarkan contoh kasus di atas deskripsi transaksinya meliputi :
a.

Menampilkan dan mengubah data penyewa yang meliputi No.Penyewa dan

Nama Penyewa.

b.

Menampilkan dan mengubah data pemilik yang meliputi No.Pemilik dan

Nama Pemilik.

c.

Menampilkan data Properti berdasarkan Pemilik properti tertentu.

Gambar 2. 15 Validasi Transaksi

3.

Memilih Index

Tujuan dari langkah ini adalah untuk menentukan apakah penambahan index
akan meningkatkan kinerja dari sistem.Index Clustered artinya . Index NonClusteredartinya. Pada DBMS MySQL primary key didefinisikan ke dalam Index
Clustered

(sumber:

http://dev.mysql.com/doc/refman/5.0/en/innodb-index-

types.html). Dari contoh kasus di atas index yang akan digunakan adalah sebagai
berikut :
Tabel 2. 8 Tabel Index
Tabel
Pemilik
Penyewa
Properti
SewaProperti

4.

Index

Clustered

NonClustered

PemilikInd
PenyewaInd
PropertiInd
SewaPropertiInd

Merancang User View

Tujuan dari langkah ini adalah untuk melihat sudut pandang pengguna terhadap
tabel dan field yang ada di dalam database.
5.

Merancang mekanisme keamanan

Tujuan dari langkah ini adalah untuk merancang mekanisme keamanan pada
basis data seperti yang telah dispesifikasikan oleh user. Mekanisme keamanan
tersebut adalah pembatasan hak akses guna menjaga keamanan data. Selain itu
perlu juga diperhatikan keamanan DBMS dan sistem operasinya.
6.

Memperkirakan kebutuhan disk

Tujuan dari langkah ini adalah untuk menghitung kapasitas penyimpanan yang
dibutuhkan oleh basis data. Hal yang harus diperhatikan adalah seberapa besar

ruang penyimpanan yang tersedia saat ini. Penyimpanan yang tersedia saat ini
akan menentukan besarnya kapasitas penyimpanan yang dibutuhkan sekarang
dan lima tahun mendatang.
MySQL Storage Requirement (sumber : http://dev.mysql.com/doc/refman/5.0/
en/storage-requirements.html) :
VARCHAR(M), ukurannya M+1 bytes.
INT, INTEGER, ukurannya 4 bytes.
TEXT, ukurannya 65535 bytes .
DATE, ukurannya 3 bytes.
DATETIME, ukurannya 8 bytes.
NUMBER(M,D), ukurannya M+2 bytes jika D > 0, M+1 bytes jika D =
0, D+2 bytes jika M < D.

2.1.3

Teori Perancangan Web Database

Menurut Eaglestone (2001, p38) Web Database System are systems in
which both Web and database technologies are used. Dapat dikatakan web
database system adalah sistem dimana dipadukannya teknologi web dan
database.
Menurut Eaglestone (2001, p262), perancangan Web Database mirip
seperti konvensional database namun terdapat dua hal yang perlu ditambahkan :

Web Page Design, hal ini meliputi :

a. Web data representation

Menampilkan web data, mengambil dari database atau masukan dari

user.
b. Web data association
Kumpulan web data, perancangan hubungan untuk petunjuk di dalam
maupun di antara web pages.
c. Web interface design
Perancangan web pages features.
Perancangan koneksi antara Web Pages dan database, meliputi :
a. Web database logical mapping
Definisi mapping antara data displayed dalam web pages dan data
stored dalam database.
b. Web database physical mapping
Implementasi mekanisme data yang dilakukan di antara web pages dan
database. Kinerja cepat dan bebas kesalahan.
Adapun skema perancangan web database :

Gambar 2. 16 Perancangan Web Database

(Sumber : Eaglestone, 2001,p264)
2.1.3.1 Perancangan Konseptual Web Data
Pada tahap ini berhubungan dengan web data analysis. Web data analysis
mendefinisikan sebuah konseptual model dari informasi yang mewakili halaman
web, serta informasi yang mewakili basis data. Data keluaran berupa ekstensi
dari konseptual data model yang meliputi hypermedia link (hubungan antara
halaman web), dan concept box (konsep web atau teknologi yang tidak dapat
digambarkan dengan basis data) (Eaglestone,2001,p288-p289).

Dari contoh kasus di atas akan menghasilkan konseptual web data model seperti
berikut ini :

Gambar 2. 17 Konseptual Web Data Model

2.1.3.2 Perancangan Logikal Web Data
Pada tahap ini mendefinisikan struktur data dari halaman web yang
sebenarnya, termasuk hubungan antara bagian-bagian dan ke halaman web lain.
Data masukan berasal dari ERD yang telah normal dari logikal data model, dan
ekstensi dari konseptual web data model. Data keluaran berupa Page Schema
yaitu data item dari basis data yang akan mewakili di dalam halaman web.
(Eaglestone,2001,p311).
2.1.3.3 Perancangan Fisikal Web Data
Pada tahap ini menjelaskan bagaimana halaman webharus dilaksanakan
dan terhubung ke database. Berhubungan juga dengan alat dan teknik yang dapat
digunakan untuk membuat database dapat diakses melalui web.

Komponen database dapat diimplementasikan sebagai ekstensi dari

server atau browser, atau mungkin eksternal ke web. Implementasi harus
menganalisa dan memutuskan bagaimana untuk mengakses basis data dari client
atau server dan di mana proses aplikasi.

Implementasi juga harus

mempertimbangkan web arsitektur (Eaglestone,2001, p348-359).

a. Two-Tier Client Server Arsitektur
Pada model ini aplikasi dibagi menjadi dua tier, yaitu First Tier dan
Second Tier.
Layanan Presentasi (First Tier)
Layanan presentasi atau logika antarmuka pengguna ditempatkan pada
mesin client. Lapisan ini berfungsi untuk menangani interaksi user
dengan aplikasi.
Layanan Data (Second Tier)
Layanan data merupakan sebuah database server atau DBMS
(Database Management Systems) yang menyediakan data bagi lapisan
layanan client atau presentasi

Gambar 2. 18 Gambar Two-Tier Client Server

b. Three-Tier Client Server Arsitektur
Model three-tier merupakan langkah pengembangan dari Arsitektur
two-tier. Model ini menambahkan komponen ketiga diantara aplikasi client
dengan aplikasi server yang disebut middle tier.
Layanan Presentasi (First Tier)
Sebagaimana dalam two-tier, layanan ini berfungsi untuk menangani
semua interaksiuser dengan aplikasi. Namun demikian, layanan ini
tidak langsung mengaksesdatabase server.
Layanan Bisnis (Middle Tier)
Layanan bisnis atau biasa disebut dengan middle tier merupakan
sebuah aplikasi yangmemberlakukan aturan-aturan bisnis, memproses
data, dan mengelola transaksi.Logika yang semula ditempatkan pada
client dipindahkan ke dalam komponenlapisan bisnis ini.
Layanan Data (Data Source Tier)

Layanan data merupakan sebuah DBMS yang mewakili satu atau lebih
penyimpanandata. Lapisan ini menyediakan permintaan data bagi
aplikasi client dengan melaluilapisan layanan bisnis.

Gambar 2. 19 Gambar Three-Tier Client Server

2.2

Teori-Teori Khusus

2.2.1

Teori-Teori Pemrograman Web

2.2.1.1 PHP : Hypertext Preprocessor
PHP adalah bahasa server side scripting yang di desain secara spesifik
untuk web. Di dalam page HTML, dapat dimasukkan kode PHP yang akan di
eksekusi setiap waktu page dikunjungi. Kode PHP diinterpretasikan pada web
server dan meng-generate HTML atau output lainnya yang akan dilihat oleh
pengguna (Welling L. and Thomson L., 2001).

Sklar (2004, p4-6) dalam bukunya Learning PHP 5 memberikan pendapat

mengenai keunggulan dari bahasa server-side scripting PHP ini yang adalah
sebagai berikut :
PHP tidak berbayar
PHP bersifat open source
PHP bersifat cross-platform
PHP banyak digunakan
PHP menyembunyikan kompleksitasnya
PHP dibuat untuk pemrograman Web
2.2.1.2 CodeIgniter
Dalam CodeIgniter User Guideversi 2.1.3, CodeIgniter dituliskan sebagai
framework yang tidak membutuhkan banyak sumber daya dan diklaim sebagai
framework PHP tercepat. Framework ini menggunakan pendekatan MVC
(Model-View-Controller) di mana business logic dan presentation dipisahkan
secara jelas sehingga desainer dan programmer dapat bekerja secara terpisah
dalam pengembangan sebuah proyek.

Gambar 2. 20 Gambar Aliran Data CodeIgniter

2.2.1.3 JavaScript
JavaScript digunakan pada jutaan halaman Web untuk meningkatkan
desain, memvalidasi form, mendeteksi browser, membuat cookie dan banyak
lagi. JavaScript menjadi bahasa scripting paling populer di Internet dan dapat
bekerja pada semua browser umum.
2.2.1.4 MySQL
Menurut Allen dan Honberger (2002, p220) dalam bukunya Mastering
PHP 4.1 MySQL merupakan bahasa pemrograman open source yang paling
banyak digunakan oleh para programmer, terutama pada Linux, karena query
basis datanya yang handal dan jarang bermasalah.
2.2.1.5 jQuery
jQuery adalah sebuah library untuk JavaScript yang ringan, cepat dan
ringkas. jQuery menyederhanakan HTML document traversing, event handling,
animation dan interaksi AJAX untuk rapid web development.

2.2.2

Teori Rekayasa Perangkat Lunak

2.2.2.1 Framework
Menurut Jeffrey L.Whitten (2004,p653) Framework adalah sebuah
subsistem dari kolaborasi objek yang menyediakan satu set layanan yang
berhubungan. Developer menggunakan Oject Frameworks untuk memanfaatkan
kemampuan penggunaan kembali dan untuk mengurangi waktu pembuatan.

2.2.2.2 Flowchart
Flowchart atau bagan alur merupakan metode untuk menggambarkan
tahap-tahap penyelesaian masalah (prosedur) beserta aliran data dengan simbolsimbol standar yang mudah dipahami. Tujuan utama penggunaan Flowchart
adalah untuk menyederhanakan rangkaian proses atau prosedur untuk
memudahkan

pemahaman

pengguna

terhadap

(Soeherman,2008,p133)

Gambar 2. 21 Simbol Input

(Sumber : Dewobroto, 2005,p14)

Gambar 2. 22 Simbol Output

(Sumber : Dewobroto, 2005,p14)

informasi

tersebut.

Gambar 2. 23 Simbol Process atau Lainnya

(Sumber : Dewobroto, 2005,p14)
2.2.2.3 Work Flow
Menurut Jeffrey L.Whitten (2004,p62)Work Flow adalah aliran transaksi
melalui proses bisnis untuk memastikan pemeriksaan yang benar dan persetujuan
diimplementasikan.