Upload
haquynh
View
232
Download
0
Embed Size (px)
Citation preview
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
(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. 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
(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 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
(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 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
(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 (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
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 -
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
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 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.
Berdasarkan contoh kasus di atas terjadi
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).
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 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
(Sumber : Dewobroto, 2005,p14)
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.