8 BAB 2 LANDASAN TEORI 2.1 Teori

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).
8
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 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 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 (Armstrong’s Axioms) :
•
Reflectivity
Jika B adalah bagian dari A, maka AB
•
Augmentation
Jika AB, maka A,CB,C
•
Transitivity
Jika AB dan BC, maka AC
•
Decomposition
Jika AB,C, maka AB dan AC
•
Union
Jika AB dan AC, maka AB,C
•
Composition
Jika AB dan CD, maka A,CB,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.
AC,
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.
AC,
A adalah Primary Key. Menjadi tabel Penyewa.
B D,G,H ;
B adalah Primary Key. H adalah Foreign Key. Menjadi tabel Properti.
HI ;
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.