BAB 2 LANDASAN TEORI - library.binus.ac.idlibrary.binus.ac.id/eColls/eThesisdoc/Bab2/2012-1-01224-IF Bab2001.pdf · Dalam penyusunan skripsi ini ada beberapa teori umum yang ... 2.1.1.2

8

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 (O’Brien, 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


– one-to-many(1:*)

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

constraint


– many-to-many(*:*)

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

constraint


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

macam 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


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 Boyce–Codd 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 sifat-

sifat(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 relasi-

relasi sehingga meminimalisasi redundansi data dan mengurangi penggunaan

tempat penyimpanan yang dibutuhkan oleh sebuah relasi dasar.Masalah-

masalah 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


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

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

B dikatakan Functionally Dependent pada A (dinotasikan A --> B), jika setiap

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

dapat terdiri atas satu atau lebih atribut). Functional dependency merupakan

sifat dari arti semantik suatu atribut dalam sebuah relasi. Direpresentasikan

dalam diagram :

Gambar 2. 7 Contoh Functional dependency


Determinant dari functional dependency mengacu kepada atribut atau

himpunan atributdisebelah kiri anak panah.

Gambar 2. 8Contoh Functional dependency


Aturan Functional Dependencies (Armstrong’s 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

Nama Penyewa

C

Alamat Properti

D

Tgl.Mulai E

Tgl.Akhir F

PE001 PR01 PR03

Andri JL.Kebon JL.Sawah

01/01/2009 01/01/2009

01/06/2009 01/12/2009

PE002 PR01 PR04

Reni JL.Kebon JL.Rawa

01/01/2008 01/01/2009

01/12/2008 01/06/2009

Sewa/bulan G

No.Pemilik H

Nama Pemilik

I 500 1000

PE01 PE03

Michael Roni

500 1500

PE01 PE04

Michael 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


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


• 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


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 -

Pemilik

Mendeskripsikan semua pemilik

yang mempunyai properti

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

Multiplicity Relationship Entitas Name

Multiplicity

Penyewa 1..* Memiliki Properti 1..* Pemilik 1..1 Memiliki Properti 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 Attributes Description

Data type & length Nulls

Multi- valued

Penyewa

No.Penyewa

NamaPenyewa

Unik, mengidentifikasi setiap penyewa Nama Penyewa

10 varchar

30 varchar

No

No

No

No

Properti

No.Properti

Alamat Sewa/bulan

Unik, mengidentifikasi setiap properti

Alamat properti Harga sewa per bulan

10 varchar

50 varchar 15 varchar

No

No No

No

No No

Pemilik No.Pemilik

NamaPemilik

Unik, mengidentifikasi setiap pemilik Nama Pemilik

10 varchar

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 Attributes Domain

Penyewa No.Penyewa

NamaPenyewa Di awali dengan PY

Properti No.Properti

Alamat Sewa/bulan

Di awali dengan PR

Pemilik No.Pemilik

NamaPemilik 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


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


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

valued 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:*)

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, Alamat, 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)

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

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.


Penyewa (No.Penyewa, NamaPenyewa)

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

Properti_Pemilik(No.Properti, AlamatProperti, Sewa/bulan, No.Pemilik,

NamaPemilik)

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


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


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 NOT NULL, NamaPemilik Nama Pemilik NOT NULL, Primary Key (No.Pemilik)); Penyewa Domain No.Penyewa : variable length character

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

Penyewa( No.Penyewa Nomor Penyewa NOT NULL, NamaPenyewa Nama Penyewa NOT NULL, Primary Key (No.Penyewa)); 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 Non-

Clusteredartinya. 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 Index Clustered Non-Clustered

Pemilik PemilikInd

Penyewa PenyewaInd

Properti PropertiInd

SewaProperti SewaPropertiInd

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

simbol standar yang mudah dipahami. Tujuan utama penggunaan Flowchart

adalah untuk menyederhanakan rangkaian proses atau prosedur untuk

memudahkan pemahaman pengguna terhadap informasi tersebut.

(Soeherman,2008,p133)

Gambar 2. 21 Simbol Input

(Sumber : Dewobroto, 2005,p14)

Gambar 2. 22 Simbol Output


Gambar 2. 23 Simbol Process atau Lainnya


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.

Documents

BAB 2 LANDASAN TEORI - library.binus.ac.idlibrary.binus.ac.id/eColls/eThesisdoc/Bab2/2012-1-01224-IF Bab2001.pdf · Dalam penyusunan skripsi ini ada beberapa teori umum yang ... 2.1.1.2