BAB 2 LANDASAN TEORI

BAB 2 LANDASAN TEORI
2.1
Database
2.1.1
Basis Data
Menurut Connolly (2002, p14), basis data adalah kumpulan data yang
terhubung secara logis, yang dapat digunakan secara bersama, dan deskripsi dari
data ini dirancang untuk memenuhi kebutuhan. Sedangkan menurut O’Brien
(2003, p145), basis data adalah sebuah kumpulan terintegrasi dari elemen data
yang terhubung secara logis. Maka dapat disimpulkan bahwa basis data adalah
suatu kumpulan data yang memiliki pola tertentu yang logis.
2.1.2
Model Relasional
Menurut Subekti (1998, p23), dalam model basis data relasional maka
data diorganisir dalam bentuk tabel-tabel dua dimensi (seperti halnya bentuk
konvensional dari file sequential). Organisasi data dalam bentuk tabel atau
disebut juga relation, terdiri atas baris (row/tuple) yang merepresentasikan
record dan kolom (column) yang merepresentasikan field (atribut).
Berbagai keuntungan yang dimiliki oleh basis data relasional adalah:
-
Bentuknya sederhana sehingga mudah dimengerti (representasi tabel)
-
Bentuknya alami (natural) mudah bagi pengguna untuk melakukan
berbagai operasi data (insert, update, delete).
Menurut Kadir (1998, p25) model relasional merupakan model yang
paling sederhana sehingga mudah dipahami oleh pengguna, serta merupakan
yang paling populer saat ini. Model relasional ini menggunakan sekumpulan
-7-
tabel dua dimensi atau berupa baris dan atribut. Relasi dirancang sedemikian
rupa sehingga dapat menghilangkan kemubaziran data dan menggunakan kunci
tamu untuk berhubungan dengan relasi lain.
Kesimpulannya model relasional merupakan data yang ditampilkan
dalam bentuk dua dimensi yang berupa beberapa baris dan kolom. Pada tiap
relasi terdapat kunci yang menghubungkan antara satu relasi dengan relasi yang
lain.
2.1.3
Kunci Relasional
Menurut Connolly (2002, p78-79) kunci relasi sangat dibutuhkan untuk
mengidentifikasi satu atau lebih atribut (disebut kunci relasi) yang memiliki nilai
unik setiap tuple dalam relasi. Macam-macam kunci relasi:
1. Kunci Sederhana (Simple Key)
Kunci sederhana adalah suatu kunci yang dibentuk oleh satu atribut.
2. Kunci Komposit (Composite Key)
Kunci Komposit adalah kunci yang disusun berdasarkan lebih dari satu
atribut.
3. Kunci Kandidat (Candidate Key)
Kunci Kandidat adalah satu atribut atau satu set minimal atribut yang
mengidentifikasikan secara unik suatu kejadian spesifik dari entity.
4. Kunci Primer (Primary Key)
Kunci Primer adalah satu atribut atau satu set minimal atribut yang tidak
hanya mengidentifikasikan secara unik suatu kejadian spesifik, tapi juga
dapat mewakili setiap kejadian dari suatu entity.
8
5. Kunci Alternatif (Alternate Key)
Kunci Alternatif adalah kunci kandidat yang tidak dipakai sebagai kunci
primer.
6. Kunci Tamu (Foreign Key)
Kunci Tamu adalah satu atribut yang melengkapi satu hubungan
(relationship) yang menunjukkan ke induknya.
2.1.4
Struktur Data Relasional
Menurut Connolly (2002, p72-74) struktur data relasional terdiri dari:
•
Relasi
Suatu relasi adalah sebuah tabel dengan kolom-kolom dan baris-baris.
•
Atribut
Suatu atribut adalah sebuah nama kolom dari suatu relasi.
•
Domain
Sebuah domain merupakan sekumpulan nilai-nilai yang diperbolehkan bagi
satu atau lebih atribut.
•
Tuple
Tuple merupakan sebuah baris dari sebuah relasi.
•
Derajat (degree)
Derajat dari suatu relasi adalah sejumlah atribut yang terkandung di
dalamnya.
•
Kardinalitas (cardinality)
Kardinalitas dari sebuah relasi adalah sejumlah tuple yang terkandung di
dalamnya.
9
•
Relasi Basis Data
Suatu koleksi dari sejumlah relasi normalisasi dengan nama-nama relasi
yang jelas.
2.1.5
Tahapan Perancangan Basis Data
Menurut Connolly (2002, p419), proses perancangan dibagi menjadi 3
tahap utama:
1.
Perancangan basis data secara konseptual
Perancangan konseptual merupakan proses konstruksi suatu
informasi yang digunakan dalam sebuah organisasi. Fase perancangan
konseptual bermula dari pembuatan data model konseptual dari
organisasi, yang sepenuhnya bebas dari pengimplementasian rincian–
rincian seperti mengenai sasaran dari manajemen sistem basis data
(DBMS), program–program aplikasi, bahasa pemrograman, platform
perangkat keras, persoalan kinerja atau pertimbangan–pertimbangan fisik
lainnya.
2.
Perancangan Basis Data secara logikal
Perancangan basis data logikal adalah proses konstruksi suatu
informasi yang digunakan dalam sebuah perusahaan berdasarkan pada
sebuah model data yang spesifik, tetapi bebas dari pertimbangan–
pertimbangan fisik lainnya.
Fase perancangan basis data secara logikal memerlukan modal
perancangan konseptual pada sebuah model logikal, yang mana
dipengaruhi oleh model data untuk target basis data (contohnya, model
10
relasional). Model data logikal adalah sumber informasi bagi fase
perancangan fisik, menyediakan perancangan fisik yang sangat penting
untuk sebuah perancangan basis data yang efisien.
3.
Perancangan Basis Data secara fisikal
Perancangan basis data secara fisik merupakan proses pembuatan
deskripsi dari implementasi basis data pada media penyimpanan
sekunder, fase ini mendeskripsikan dasar relasi, berkas organisasi dan
indeks untuk mencapai pengaksesan data yang efisien, dan beberapa
batasan hubungan yang utuh dan tingkat keamanan.
Fase perancangan basis data secara fisik memperbolehkan
perancang membuat keputusan–keputusan berdasarkan bagaimana basis
data diimplementasikan, agar perancangan fisikal ditoleransi sebuah
untuk sebuah manajemen sistem basis data yang spesifik. Ada timbal
balik antara perancangan logical dan perancangan fisikal, karena
keputusan–keputusan
diambil
selama
perancangan
fisikal
mengembangkan kinerja yang bisa mempengaruhi model data logikal.
2.1.6
Entity-Relational Diagram (ERD)
Menurut Date (2000, p427–429), entity relational diagram (ER Diagram)
merupakan sebuah teknik untuk menggambarkan struktur logis dari sebuah basis
data dalam suatu cara bergambar. Tentu saja, popularitas dari sebuah model ER
seperti sebuah pendekatan pada perancangan basis data dapat dilengkapi lebih
untuk keberadaan tehnik diagram ER daripada untuk beberapa kasus lainnya.
11
2.2
Normalisasi
2.2.1 Pengertian Normalisasi
Normalisasi adalah sebuah teknik formal untuk menganalisis relasi
berdasarkan primary key (candidate key) dan ketergantungan fungsional
(Connolly, 2002, p386). Teknik tersebut mencakup serangkaian aturan yang
dapat digunakan untuk menguji relasi individual, sehingga sebuah basis data
dapat dinormalisasi pada derajat tertentu. Ketika syarat tidak terpenuhi, relasi
yang tidak sesuai syarat harus diuraikan ke dalam relasi yang secara individu
memenuhi syarat-syarat normalisasi. Tujuan dari proses normalisasi adalah untuk
menghilangkan redundansi data (misalnya menyimpan data yang sama di
beberapa tabel) dan memastikan ketergantungan data yang ada sudah benar
(hanya menyimpan data yang berhubungan ke dalam sebuah tabel). Normalisasi
mendukung para perancang basis data dengan memberikan serangkaian
percobaan yang dapat digunakan dalam relasi individual sehingga skema relasi
tersebut dapat dinormalisasi ke dalam bentuk yang lebih spesifik untuk
menghindari kejadian yang memungkinkan terjadinya update anomaly
(Connolly, 2002, p377). Normalisasi biasanya dilakukan dalam beberapa tahap.
Masing-masing tahap berkaitan dengan bentuk normal tertentu yang telah
diketahui propertinya. Dalam pemodelan data, sangatlah penting untuk mengenal
normalisasi tingkat pertama (1NF) yang merupakan kondisi kritis untuk
membuat relasi-relasi yang diperlukan, sedangkan bagian bentuk normal yang
lain merupakan pilihan (optional). Namun, untuk menghindari terjadinya update
anomaly, maka dalam proses normalisasi setidaknya harus sampai pada bentuk
12
normal ketiga (Connolly, 2002, p386).
2.2.2 Pengertian Anomali
Menurut Connolly (2002, p376), anomali, adalah suatu masalah yang
timbul seperti: data ganda, data hilang, tempat pemborosan memori, dan data
yang tidak konsisten akibat proses penghapusan data, pembaruan data,
pemasukan data, dan penggantian data.
Staf
NoStaf
NamaStaf
Jabatan
Gaji
NoCabang
SL21
John White
Manager
30000
B005
SG37
Ann Beach
Assistant
12000
B003
SG14
David Ford
Supervisor
18000
B003
SA9
Mary Howe
Assistant
9000
B007
SG5
Susan Brand
Manager
24000
B003
SL41
Julie Lee
Assistant
9000
B005
Cabang
NoCabang
AlamatCabang
B005
22 Deer Rd, London
B007
16 Argyll St, Aberdeen
B003
163 Main St, Glasgow
Tabel 2.1 Relasi Staf dan Cabang
13
StafCabang
noStaf
namaStaf
jabatan
Gaji
noCabang
AlamatCabang
SL21
John White
Manager
30000
B005
22 Deer Rd, London
SG37
Ann Beach
Assistant
12000
B003
163 Main St, Glasgow
SG14
David Ford
Supervisor
18000
B003
163 Main St, Glasgow
SA9
Mary Howe
Assistant
9000
B007
16 Argyll St, Aberdeen
SG5
Susan Brand
Manager
24000
B003
163 Main St, Glasgow
SL41
Julie Lee
Assistant
9000
B005
22 Deer Rd, London
Tabel 2.2 Relasi StafCabang
Menurut Subekti (1998, p22), anomali (kejanggalan) akan muncul
terhadap operasi dasar karena adanya fakta hubungan many to many (baik untuk
operasi insert, delete, maupun update):
•
Anomali insert
Ada dua jenis insertion anomaly yang dapat digambarkan dengan
menggunakan relasi pada contoh tabel 2.2 di atas.
•
Untuk memasukkan anggota baru staf ke dalam relasi StafCabang,
perincian Cabang di mana staf ditempatkan perlu dimasukkan.
Sebagai contohnya, untuk memasukkan perincian staf baru yang akan
ditempatkan pada cabang nomor B007, perincian cabang nomor B007
perlu dimasukkan dengan benar, sehingga perincian cabang konsisten
dengan nilai cabang B007 di tuple lain dalam relasi StafCabang.
Relasi yang ditunjukkan pada tabel 2.1 tidak mengalami data yang
tidak konsisten, karena hanya memasukkan nomor cabang dengan
tepat untuk masing-masing staf dalam relasi Staf. Sedangkan
14
perincian cabang nomor B007 disimpan dalam basis data sebagai
tuple tersendiri dalam relasi Cabang.
•
Untuk memasukkan perincian cabang baru yang tidak mempunyai
nomor anggota staf pada relasi StafCabang, perlu memasukkan nilai
null pada atribut staf, seperti noStaf. noStaf adalah primary key dari
relasi StafCabang, sehingga memasukkan nilai null pada noStaf akan
melanggar konsep integritas data, dan hal semacam ini tidak
diperbolehkan. Oleh karena itu, nilai null tidak bisa dimasukkan pada
noStaf ke dalam cabang baru pada relasi StafCabang. Perancangan
yang ditunjukkan pada tabel 2.1 menghindari masalah ini karena
perincian cabang yang dimasukkan pada relasi Cabang terpisah dari
perincian staf.
•
Anomali delete
Jika ingin menghapus sebuah tuple dari relasi StafCabang yang
merepresentasikan anggota staf yang ditempatkan pada cabang, maka
perincian tentang cabang juga hilang dari basis data. Sebagai contohnya,
jika ingin menghapus tuple NoStaf SA9 (Mary Howe) dari relasi
StafCabang, perincian yang berhubungan dengan cabang nomor B007 akan
hilang dari basis data. Rancangan pada relasi yang ditunjukkan pada tabel
2.1 menghindari masalah ini, karena tuple cabang disimpan secara terpisah
dari tuple staf dan hanya atribut NoCabang yang berhubungan dengan
kedua relasi tersebut. Jika ingin menghapus tuple NoStaf SA9 dari relasi
Staf, perincian cabang nomor B007 tetap tidak terpengaruh dalam relasi
15
Cabang.
•
Anomali update:
Jika ingin mengubah nilai dari salah satu atribut untuk cabang tertentu pada
relasi StafCabang, contohnya AlamatCabang dari cabang nomor B003,
tuple dari semua staf yang ditempatkan pada cabang tersebut perlu
diperbaharui (update). Jika perubahan ini tidak mengubah semua tuple pada
relasi StafCabang dengan tepat, maka basis data menjadi tidak konsisten.
Pada contoh ini, cabang nomor B003 akan mempunyai AlamatCabang yang
berbeda untuk tuple staf yang berbeda.
2.2.3
Dependensi (Ketergantungan)
Menurut Kadir (1999, p680), dependensi merupakan konsep yang
mendasari normalisasi. Dependensi menjelaskan hubungan antara atribut, atau
secara lebih khusus menjelaskan nilai suatu atribut yang menentukan nilai atribut
lainnya. Dependensi ini kelak menjadi acuan bagi pendekomposian data ke
dalam bentuk yang paling efisien.
Untuk
menentukan
cara
yang
sistematik
dalam
mengambil
ketergantungan, perlu diketahui sejumlah inference rule yang dapat digunakan
untuk mengambil ketergantungan baru dari sejumlah ketergantungan yang
diberikan.
Enam
aturan
yang
dikenal
sebagai
inference
rule
ketergantungan fungsional adalah sebagai berikut (Elmasri, 2000, p479).
1. Reflektif
: Jika A ⊇ B, maka A Æ B
2. Augmentasi
: Jika A Æ B, maka A,C Æ B,C
3. Transitif
: Jika A Æ B dan B Æ C, maka A Æ C
16
untuk
4. Dekomposisi
: Jika A Æ B,C, maka A Æ B dan A Æ C
5. Union
: Jika A Æ B dan A Æ C, maka A Æ B,C
6. Pseudotransitif : Jika A Æ B dan DB Æ E, maka AD Æ E
Misalnya skema R = (A, B, C, G, H ,I) dan sejumlah ketergantungan
fungsional F {A Æ B, A Æ C, CG Æ H, CG Æ I, B Æ H}. Dengan
menggunakan inference rule tersebut maka akan didapatkan F+ sebagai berikut :
•
A Æ H didapat dari A Æ B dan B Æ H dengan menggunakan aturan
transitif.
•
CG Æ HI didapat dari CG Æ H dan CG Æ I dengan menggunakan aturan
union.
•
AG Æ I didapat dari A Æ C dan CG Æ I dengan menggunakan aturan
pseudotransitif.
Terdapat cara lain juga untuk mendapatkan AG Æ I. Dengan
menggunakan aturan augmentasi, A Æ C menjadi AG Æ CG, kemudian
menggunakan CG Æ I dengan aturan transitif diperoleh AG Æ I.
Macam-macam dependensi:
•
Dependensi fungsional, adalah jenis dependensi yang banyak diulas pada
literatur basis data. Dependensi fungsional didefinisikan sebagai berikut:
Suatu atribut Y mempunyai dependensi fungsional terhadap atribut X jika
dan hanya jika setiap nilai X berhubungan dengan sebuah nilai Y (XÆY).
•
Dependensi fungsional sepenuhnya, dapat dijelaskan sebagai berikut:
Suatu atribut Y mempunyai dependensi fungsional penuh terhadap atribut
X jika:
17
™ Y mempunyai dependensi fungsional terhadap X.
™ Y tidak memiliki dependensi terhadap bagian dari X.
•
Dependensi total, dapat didefinsikan sebagai berikut:
Suatu atribut Y mempunyai dependensi total terhadap atribut X jika:
™ Y mempunyai dependensi fungsional terhadap X.
™ X mempunyai dependensi fungsional terhadap Y.
Dependensi ini dapat dinyatakan dengan notasi XÅÆY
•
Dependensi multivalued
Suatu kondisi di mana terdapat ketergantungan antara atribut
(contohnya, A, B, and C) di suatu relasi, di mana untuk setiap nilai dari A
terdapat sejumlah nilai dari B dan sejumlah nilai dari C. Tetapi, antara B
dan C tidak saling tergantung atau tidak ada hubungan satu sama lainnya
Terjadinya multivalued dependencies dalam suatu relasi dikarenakan
pada bentuk 1NF tidak diperbolehkan adanya repeating groups (atribut
dalam satu baris mempunyai nilai lebih dari satu). Contohnya, jika dalam
suatu relasi terdapat dua multivalued atribut, kita harus mengulang setiap
nilai dari satu atribut dengan setiap nilai dari atribut lain, untuk menjaga
konsistensinya. Hal ini menyebabkan multivalued dependencies dan
menghasilkan redundansi data.
•
Dependensi transitif, adalah sebagai berikut
Atribut Z mempunyai dependensi transitif terhadap X bila:
™ Y mempunyai dependensi fungsional terhadap X.
™ Z mempunyai dependensi fungsional terhadap Y.
18
2.2.6
Proses Normalisasi
Pertama kali dikembangkan oleh E.F.Codd (1972 b). Proses normalisasi
sering dilakukan sebagai rangkaian test terhadap suatu hubungan untuk
menentukan apakah memenuhi atau melanggar kebutuhan dari bentuk normal
yang ditentukan.
1. Bentuk normal kesatu (1NF)
Mengidentifikasikan dan membuang atribut yang berulang (repeating
groups) dan memiliki nilai yang lebih dari satu (multivalued). Grup yang
berulang (repeating groups) disini maksudnya adalah sebuah atribut atau
sekumpulan atribut dalam tabel yang mengandung banyak nilai untuk satu
kejadian.
Ada dua pendekatan yang umum digunakan untuk menghilangkan
grup yang berulang dalam tabel yang tidak normal (Connolly, 2002, p388) :
a. Menghilangkan grup yang berulang dengan memasukkan data yang
tepat pada kolom kosong dari baris yang mengandung data yang
berulang. Dengan kata lain, kolom yang kosong tersebut diisi dengan
menggandakan data yang tidak berulang (jika diperlukan). Tabel yang
dihasilkan merupakan suatu relasi yang mengandung nilai tunggal pada
irisan untuk tiap baris dan kolom, dan tabel yang dihasilkan sudah
berada dalam bentuk normal pertama.
b. Menghilangkan grup yang berulang dengan menempatkan data yang
berulang bersama dengan salinan atribut key asli. Sebuah primary key
diidentifikasi untuk relasi baru. Kadang-kadang tabel yang tidak normal
19
mengandung lebih dari satu grup yang berulang. Dalam kasus tersebut,
pendekatan ini digunakan berulang-ulang sampai tidak ada grup yang
berulang lagi.
SewaKlien
noKlien
nmKlien
noProperti
CR76
John
PG4
Kay
AlmtPro
awalSewa
akhirSewa
Sewa
noPemilik
nmPemilik
6 Lawrence
1-Jul-00
31–Aug -
350
CO40
Tina
St, Glasgow
PG16
5 Novar Dr,
01
Murphy
1-Sep-01
1-Sep-02
450
CO93
Tony Shaw
1-Jul-00
31 – Aug -
350
CO40
Tina
Glasgow
CR65
Aline
PG4
Stewart
6 Lawrence
St, Glasgow
PG36
2 Manor Rd
01
Murphy
10-Oct-00
1-Dec-01
375
CO93
Tony Shaw
1-Sep-01
1-Sep-02
450
CO93
Tony Shaw
Glasgow
PG16
5 Novar Dr,
Glasgow
Tabel 2.3 Tabel SewaKlien yang belum dinormalisasi
noKlien diidentifikasi sebagai kunci atribut dalam tabel yang tidak
normal (sewaKlien). Struktur dari grup yang berulang adalah {noProperti,
AlmtPro, awalSewa, akhirSewa, Sewa, noPemilik, nmPemilik}.
Akibatnya, terdapat beberapa nilai pada irisan untuk baris dan kolom
tertentu. Sebagai contohnya, untuk klien yang bernama John Kay terdapat
dua nilai noProperti (PG4 dan PG16). Untuk mengubah tabel yang tidak
normal ke dalam bentuk normal pertama, perlu dipastikan bahwa hanya
terdapat nilai yang tunggal pada irisan dari masing-masing baris dan
kolom. Oleh karena itu grup yang berulang harus dihilangkan.
SewaKlien
20
noKlien
nmKlien
noProperti
AlmtPro
awalSewa
akhirSewa
Sewa
noPemilik
nmPemilik
CR76
John
PG4
6 Lawrence
1-Jul-00
31 – Aug -
350
CO40
Tina
Kay
CR76
St, Glasgow
John
PG16
Kay
CR65
Aline
PG4
1-Sep-02
450
CO93
Aline
Aline
6 Lawrence
PG36
2 Manor Rd
1-Jul-00
31 – Aug -
350
CO40
01
10-Oct-00
1-Dec-01
Stewart
5 Novar Dr,
Tina
Murphy
375
CO93
Glasgow
PG16
Tony
Shaw
St, Glasgow
Stewart
CR65
1-Sep-01
Murphy
Glasgow
Stewart
CR65
5 Novar Dr,
01
Tony
Shaw
1-Sep-01
1-Sep-02
450
CO93
Glasgow
Tony
Shaw
Tabel 2.4 Relasi SewaKlien pada bentuk normal pertama
Dengan menggunakan pendekatan pertama, grup yang berulang
dihilangkan dengan memasukkan data klien yang tepat ke tiap baris. Hasil
bentuk normal pertama relasi SewaKlien dapat dilihat pada tabel 2.4.
Candidate key untuk relasi SewaKlien diidentifikasi sebagai key gabungan
(composite
key)
yang
terdiri
dari
(noKlien,
noProperti),
(noKlien,awalSewa) dan (noProperti, awalSewa). Key yang dipilih sebagai
primary key adalah (noKlien, noProperti) dan untuk lebih jelasnya, atribut
yang dipilih sebagai primary key diletakkan di sebelah kiri dalam relasi.
Atribut akhirSewa tidak tepat sebagai komponen dari candidate key karena
mungkin berisi nilai null. Relasi SewaKlien dapat didefinisikan sebagai
berikut : SewaKlien (noKlien, noProperti, nmKlien, AlmtPro, awalSewa,
akhirSewa, sewa, noPemilik, nmPemilik)
Relasi SewaKlien berada dalam bentuk normal pertama jika terdapat
nilai tunggal pada irisan dari tiap baris dan kolom. Relasi tersebut
21
mengandung data yang mendeskripsikan klien, properti yang disewakan,
dan pemilik properti secara berulang-ulang. Sebagai hasilnya, relasi
SewaKlien mengandung redundansi data. Jika relasi dalam bentuk normal
pertama diimplementasikan, maka akan terjadi update anomaly. Untuk
mengatasi hal tersebut maka relasi harus diubah ke dalam bentuk normal
kedua.
Dengan menggunakan pendekatan kedua, grup yang berulang
dihilangkan dengan menempatkan data yang berulang bersama dengan
salinan atribut key asli (noKlien) dalam relasi yang terpisah seperti yang
ditunjukkan pada tabel 2.5. Kemudian primary key dapat diidentifikasi
untuk relasi yang baru, dan hasil relasi dalam bentuk normal pertama
adalah sebagai berikut :
Klien
(noKlien, nmKlien)
PemilikPropertiSewa
(noKlien,
noProperti,
AlmtPro,awalSewa,akhirSewa, Sewa, noPemilik, nmPemilik)
Kedua relasi Klien dan PemilikPropertiSewa berada dalam bentuk
normal pertama di mana terdapat nilai tunggal pada irisan dari tiap baris
dan kolom. Relasi Klien berisi data yang mendeskripsikan klien dan relasi
PemilikPropertiSewa berisi data yang mendeskripsikan properti yang
disewa oleh klien dan pemilik properti. Relasi pada tabel 2.5 juga berisi
redundansi data yang menyebabkan terjadinya update anomaly.
PemilikPropertiSewa
22
noKlien
noProperti
CR76
PG4
AlmtPro
awalSewa
akhirSewa
Sewa
noPemilik
nmPemilik
6 Lawrence St,
1-Jul-00
31 – Aug
350
CO40
Tina
Glasgow
CR76
PG16
5
Novar
– 01
Dr,
Murphy
1-Sep-01
1-Sep-02
450
CO93
Tony Shaw
1-Jul-00
31 – Aug
350
CO40
Tina
Glasgow
CR65
PG4
6 Lawrence St,
Glasgow
CR65
PG36
2
Manor
– 01
Murphy
Rd,
10-Oct-00
1-Dec-01
375
CO93
Tony Shaw
Dr,
1-Sep-01
1-Sep-02
450
CO93
Tony Shaw
Glasgow
CR65
PG16
5
Novar
Glasgow
Klien
noKlien
nmKlien
CR76
John Kay
CR56
Aline Stewart
Tabel 2.5 Relasi Klien dan PemilikPropertiSewa pada 1NF
Suatu hubungan dinyatakan normal pertama apabila :
a. Setiap dari baris dan kolom berisi atribut yang bernilai tunggal.
b. Kunci primer telah ditentukan
c. Attribut yang mempunyai nilai banyak (multivalued) telah dihilangkan.
2. Bentuk normal kedua (2NF)
Ketergantungan Fungsional (Functional Dependency)
Bergantung fungsional dapat didefinisikan sebagai berikut : Jika A dan B
merupakan bagian atribut dari suatu hubungan, B bergantung penuh pada A,
jika dan hanya jika setiap nilai A berhubungan dengan sebuah nilai B.
23
B is Functionally
A
B
Dependent on A
Position on Functionally
staff No
Position
Dependent on staffNo
Position is not Functionally
Position
staffNo
Dependent on Position
Gambar 2.3 contoh Functional Dependency
Bergantung fungsional penuh dapat didefinisikan sebagai berikut : Jika A
dan B adalah atribut dari suatu hubungan ,
B bergantung fungsional
sepenuhnya kepada A jika B bergantung fungsional terhadap A, tetapi tidak
memiliki ketergantungan kepada subset A lainnya.
Suatu hubungan berada dalam bentuk normal kedua jika :
a. Berada pada bentuk normal pertama
b. Atribut bukan kunci primer (non primary key) telah dihilangkan atau
semua atribut bukan kunci primer bergantung fungsional sepenuhnya
kepada kunci primer.
3. Bentuk normal ketiga (3NF)
Ketergantungan Transitif (Transitive Dependency)
Ketergantungan transitif dapat didefinisikan sebagai berikut : Pada
kondisi dimana A , B dan C adalah atribut dari suatu hubungan. Jika AÆB
dan BÆC, maka C merupakan ketergantungan transitif pada A dan B
24
(dimana A tidak bergantung fungsional terhadap B atau C)
Suatu hubungan berada pada bentuk normal ketiga jika :
a. Berada pada bentuk normal pertama dan kedua
b. Setiap atribut bukan kunci tidak memiliki dependensi transitif terhadap
kunci primer.
4. Bentuk normal Boyce – Codd Normal Form (BCNF)
Pertama kali diperkenalkan oleh R.Boyce dan E.F.Codd (Codd, 1974).
Suatu hubungan berada pada bentuk normal BCNF (Boyce Codd Normal
Form) jika hanya jika setiap determinan adalah kunci kandidat. Bentuk
normal BCNF merupakan perbaikan dari bentuk normal yang ketiga. Tetapi
tidak menutup kemungkinan bahwa bentuk normal ketiga memiliki anomali,
sehingga perlu dinormalisasi lagi. Suatu relasi yang memenuhi BCNF selalu
memenuhi 3NF, tetapi belum tentu bentuk normal 3NF memenuhi bentuk
normal BCNF
Contoh (Elmasri, 2000, p495):
Asumsinya adalah setiap INSTRUCTOR hanya mengajar satu COURSE
STUDENT
COURSE
INSTRUCTOR
FD1
FD2
Tabel 2.6 Relasi Teach
Karena determinant pada FD2 bukan kunci kandidat, maka relasi ini
melanggar ketentuan BCNF. Untuk mengubahnya ke dalam bentuk BCNF,
relasi di atas harus di dekomposisi menjadi dua relasi yaitu:
25
INSTRUCTOR
COURSE
FD1
INSTRUCTOR
STUDENT
FD1
Tabel 2.7 Relasi Teach setelah didekomposisi
5. Bentuk normal keempat (4NF)
Ketergantungan nilai banyak (MultiValued Atribut)
Menurut Connolly (2002, p407-408) MultiValued Dependecy adalah
suatu kondisi di mana terdapat ketergantungan antara atribut (contohnya, A,
B, and C) di suatu relasi, di mana untuk setiap nilai dari A terdapat sejumlah
nilai dari B dan sejumlah nilai dari C. Tetapi, antara B dan C tidak saling
tergantung atau tidak ada hubungan satu sama lainnya.
Terjadinya multivalued dependencies dalam suatu relasi dikarenakan
pada bentuk 1NF tidak diperbolehkan adanya repeating groups (atribut
dalam satu baris mempunyai nilai lebih dari satu). Contohnya, jika dalam
suatu relasi terdapat dua multivalued atribut, kita harus mengulang setiap
nilai dari satu atribut dengan setiap nilai dari atribut lain, untuk menjaga
konsistensinya. Hal ini menyebabkan multivalued dependencies dan
menghasilkan redundansi data.
BranchStaffOwner
26
branchNo
sName
oName
B003
Ann Beech
Carol Farrel
B003
David Ford
Carol Farrel
B003
Ann Beech
Tina Murphy
B003
David Ford
Tina Murphy
Tabel 2.8 Relasi BranchStaffOwner
Seperti terlihat, MVD timbul karena ada dua hubungan 1:* yang independent
dalam relasi BranchStaffOwner yaitu:
branchNo
sName
branchNo
oName
Suatu relasi dikatakan sudah berada dalam 4NF jika relasi tersebut sudah
dalam BCNF dan tidak mengandung nontrivial multivalued dependencies.
Sebuah MVD A
B dalam suatu relasi R dikatakan trivial jika B
adalah subset dari A dan A U B = R. Sebuah MVD dikatakan nontrivial jika
kedua kondisi pada trivial tidak dipenuhi .Seperti pada contoh di atas
terdapat nontrivial MVD, maka untuk mengubahnya ke dalam 4NF, relasi di
atas perlu didekomposisi menjadi relasi BranchStaff dan BranchOwner.
branchNo
sName
branchNo
oName
B003
Ann Beech
B003
Carol Farrel
B003
David Ford
B003
Tina Murphy
Tabel 2.9 Relasi BranchStaffOwner setelah didekomposisi
27
Sekarang kedua relasi tersebut sudah dalam 4NF karena relasi
BranchStaff mengandung trivial MVD branchNo
sName, dan relasi
BranchOwner juga mengandung trivial MVD branchNo
oName.
6. Bentuk normal kelima ( 5NF )
Satu hubungan dikatakan berada pada bentuk kelima jika dan hanya jika
suatu hubungan tidak memiliki join dependensi. Bentuk normal keempat dan
kelima diperkenalkan oleh Fagin, hanya dipakai pada kasus–kasus khusus,
terdapat hubungan yang mengandung dependensi nilai banyak.
2.2.7
Overnormalisasi
Tabel–tabel yang memenuhi 5NF terkadang didekomposisi lagi. Prosesnya
dikenal dengan sebutan overnormalisasi. Tujuannya adalah untuk meningkatkan
kinerja, caranya adalah dengan memperlihatkan permintaan terhadap data yang
sering dilakukan. Kolom–kolom data yang sering diperlukan diletakkan pada
tabel tersendiri, terpisah dengan kolom–kolom data yang jarang diperlukan.
Alasan yang lain , tabel yang terlalu banyak memiliki kolom dapat menimbulkan
persoalan yang disebut deadlock (saling mengunci) pada pengaksesan yang
serentak (sejumlah pengguna mengakses baris yang sama).
Namun perlu juga diperlihatkan bahwa tidak selamanya pendekomposisian
terhadap tabel yang telah memenuhi 5NF dapat meningkatkan kinerja. Pada
kenyataannya tabel yang terlalu pendek (sedikit memiliki kolom) juga
menimbulkan persoalan peningkatan waktu CPU dan juga memerlukan banyak
I/O disk ketika terjadi penggabungan data (misalnya untuk penyajian laporan).
28
2.3
Algoritma Normalisasi BCNF dan 4NF
2.3.1 Algoritma Normalisasi BCNF
Algoritma yang dipakai untuk menghasilkan bentuk BCNF menurut
Elmasri (2000, p509) :
Set D := {R};
While there is a relation schema Q in D that is not in BCNF do
{
choose a relation schema Q in D that is not in BCNF;
find a functional dependency X Æ Y in Q that violates BCNF;
replace Q in D by two relation schemas (Q – Y) and (X U Y);
}
Keterangan : untuk melakukan testing bahwa suatu relation schema dalam
bentuk BCNF atau tidak dapat dilakukan dengan 2 cara :
a.
Setiap functional dependency X -> Y di Q, apabila X bukan berisi semua
attribute di Q, maka X -> Y menyalahi BCNF karena X bukan superkey
dari Q
b.
Jika suatu relational schema Q menyalahi BCNF , terdapat sepasang
attribute A dan B di Q berupa {Q – {A,B}} -> A. Dengan melihat
closure {Q – {A,B}}* untuk setiap {A,B} dari Q dan memeriksa setiap
closure terdapat A (atau B) maka kita dapat memperkirakan apakah Q
pada BCNF.
Asumsi : tabel-tabel masukan sudah dalam bentuk 3NF. Adapun algoritma
untuk menghasilkan bentuk 1NF - 3NF ::
29
Set G := F
Replace each functional dependency X -> {A1,A2,…,An} in G by the n functional
dependencies X -> A1, X -> A2, …, X -> An.
For each functional dependency X -> A in G
For each attribute B that is an element of X
If ((G – {X->A}) U {(X – {B}) -> A}) is equivalent to G
Then replace X -> A with (X – {B}) -> A in G
For each remaining functional dependency X -> A in G
If (G – {X – A}) is equivalent to G
Then remove X -> A from G
For each left hand side X of a functional dependency that appears in G create a
relation schema in D with attributes { X U {A1} U {A2} … U {An}}, where X ->
A1 , X -> A2, … , X -> Ak are only dependencies in G with X as left-hand-side (
X is the key of this relation ).
If none of the relation schemas in D contains a key of R, then create one more
relation schema in D that contains attributes that form a key of R.
2.3.2 Algoritma Normalisasi 4NF
Algoritma yang dipakai untuk menghasilkan bentuk 4NF menurut
Elmasri (2000, p519) :
Set D := {R};
While there is a relation schema Q in D that is not in 4NF do
{
choose a relation schema Q in D that is not in 4NF;
30
find a nontrivial MVD X Æ Y in Q that violates 4NF;
replace Q in D by two relation schemas (Q – Y) and (X U Y);
}
Asumsi : tabel-tabel masukan sudah dalam bentuk BCNF.
2.4
Perancangan Piranti Lunak
Menurut Pressman (2001, p6), yang dimaksud dengan piranti lunak
adalah (1) kumpulan instruksi (program komputer) yang jika dieksekusi akan
menyediakan fungsi dan dayaguna yang diinginkan, (2) kumpulan struktur data
yang memungkinkan program untuk memanipulasi informasi dengan memadai,
dan (3) kumpulan dokumen yang menggambarkan operasi dan penggunaan
program. Dalam perancangan piranti lunak terdapat beberapa macam model
seperti linier , spiral , incremental , dll. Penyusun memilih model waterfall (
linier ) karena langkah – langkahnya berurutan dan sistematis.
System/information
engineering
analysis
design
code
test
Gambar 2.2 Model linear sekuensial
Langkah-langkah dalam model waterfall adalah sebagai berikut:
1.
Rekayasa dan penyusunan sistem/informasi
Tahap ini dimulai dengan menyusun kebutuhan (requirement)
31
untuk
seluruh elemen sistem dan kemudian mengalokasikan beberapa
subset dari kebutuhan tersebut pada piranti lunak (software). Proses ini
sangat penting ketika piranti lunak harus berinteraksi dengan elemen
yang lainnya seperti, perangkat keras (hardware), manusia, dan basis data
(database).
2.
Analisis kebutuhan piranti lunak
Proses pengumpulan kebutuhan pada tahap ini lebih diintensifkan
dan difokuskan pada piranti lunak Pengembang piranti lunak harus
memahami tentang fungsi yang dibutuhkan, perilaku, dayaguna dan
tampilan layar dari piranti lunak yang akan dikembangkan.
3.
Perancangan (Design)
Perancangan piranti lunak sesungguhnya merupakan proses
bertahap yang berfokus pada empat atribut dari sebuah program: struktur
data, arsitektur piranti lunak, representasi tampilan layar, dan detail
prosedural (algoritmik). Proses desain menerjemahkan kebutuhan
menjadi suatu representasi dari piranti lunak yang dapat diakses sebelum
pengkodean dimulai.
4.
Pembuatan kode (code generation)
Proses penerjemahan bentuk desain menjadi bentuk yang dapat
dibaca oleh mesin.
5.
Pengujian (testing)
Pengujian program dilakukan setelah kode dihasilkan. Proses
pengujian difokuskan pada bagian internal software secara logis,
memastikan bahwa setiap pernyataan (statement) telah diuji, dan pada
32
bagian eksternal fungsi, di mana dilakukan pengujian untuk menemukan
error dan memastikan bahwa masukan yang ditentukan akan memberikan
hasil yang diharapkan.
6.
Pemeliharaan (Maintenance)
Ketika piranti lunak telah selesai dikembangkan dan dikirimkan
kepada pelanggan, piranti lunak tersebut mungkin akan mengalami
masalah atau error yang tidak diharapkan sebelumnya. Untuk itu, tahapan
pemeliharaan dilakukan dengan tujuan melakukan penyesuaian dan
perbaikan pada piranti lunak tersebut.
2.5
Alat Bantu Perancangan Sistem
2.2.1
Use Case Diagram
Use Case Diagram adalah diagram yang menggambarkan interaksi antara
sistem dengan sistem luar dan user. Dengan kata lain, secara grafik
menggambarkan siapa yang akan menggunakan sistem dan dengan cara
bagaimana user bisa berinteraksi dengan sistem. Diagram ini secara grafik
menggambarkan sistem sebagai kumpulan use case, actor (user) dan hubungan
yang terjadi. (Whitten, 2004, p271)
2.2.1.1 Use Case
Use case adalah alat untuk menggambarkan fungsi-fungsi sistem dari
perspektif pengguna luar dan dalam cara dan istilah yang mereka mengerti
(Whitten, 2004, p272). Use case digambarkan secara grafik oleh sebuah elips
horizontal dengan nama yang muncul di atas, di bawah atau di dalam elips.
Sebuah use case menggambarkan tujuan sistem dan rangkaian kegiatan dan
33
interaksi yang dilakukan user
dalam mencapai tujuan tersebut. Use case
merupakan hasil penguraian batasan-batasan fungsionalitas sistem ke dalam
pernyataan – pernyataan yang lebih pendek.
2.2.1.2 Actor
Actor adalah segala sesuatu yang perlu berinteraksi dengan sistem untuk
pertukaran informasi (Whitten, 2004, p273).
2.2.1.3 Relationship
Relationship digambarkan dengan garis di antara dua simbol di dalam diagram
use case. Arti hubungan yang terjadi bisa bervariasi tergantung bagaimana garis
digambarkan dan tipe simbol apa yang mereka hubungkan (Whitten, 2004,
p273).
Jenis – jenis hubungan yang terjadi ada lima, yaitu
•
Association
Sebuah hubungan antara sebuah actor dengan sebuah use case dimana
interaksi terjadi di antara mereka (Whitten, 2004, p274).
•
Extend
Sebuah use case yang terdiri dari langkah-langkah yang dikutip dari use
case yang lebih kompleks untuk menyederhanakan use case asli dan
memperluas
fungsionalitasnya.
Biasanya
ditandai
dengan
label
“<<extend>>” (Whitten, 2004, p274).
•
Include
Sebuah use case yang mengurangi redundansi di antara dua atau lebih use
case dengan menggabungkan langkah-langkah yang sering ditemukan.
34
Hubungannya digambarkan dengan “<<uses>>” (Whitten, 2004, p274).
•
Depends on
Hubungan yang menggambarkan ketergantungan antar use case. Jenis
hubungan ini digambarkan dengan garis yang berpanah dimulai dari satu
use case menunjuk ke use case tempat ia bergantung. Garis hubungan
ditandai dengan label “<<depends on>>” (Whitten, 2004, p275).
•
Inheritance
Hubungan yang terjadi jika terdapat dua atau lebih actor yang memiliki
sifat yang sama (Whitten, 2004, p275).
2.2.2
Diagram Alir (flowchart)
Menurut O’Brien (2003, pG-8), diagram alir merupakan suatu
representasi grafis di mana simbol-simbol digunakan untuk merepresentasikan
operasi, data, aliran, logika, perlengkapan, dan seterusnya. Suatu diagram alir
program mengilustrasikan struktur dan bagian dari operasi program tersebut,
sementara sebuah diagram alir sistem mengilustrasikan komponen-komponen
dan aliran sistem informasi.
Tiga konsep utama dalam pemrograman terstruktur yaitu sekuensial,
kondisi (condition), dan pengulangan (repetition) (Pressman, 2001, p424-425).
Sekuensial mengimplementasikan langkah-langkah proses yang penting dalam
spesifikasi algoritma-algoritma. Kondisi menyediakan kemudahan untuk
memilih proses berdasarkan logika, dan pengulangan untuk melakukan proses
perulangan.
35
Gambar 2.3 Konsep Diagram Alir
36