1 NORMALISASI
Overview
|
||
Bab ini akan membahas konsep normalisasi database berikut konsep-konsep lain yang mendasarinya. Dalam bab
ini juga akan ditampilkan contoh penerapan normalisasi untuk tabel-tabel
sederhana dalam kasus database
akademik di sebuah perguruan tinggi.
|
||
Tujuan
|
||
1.
Mahasiswa memahami definisi dan
tujuan normalisasi
2.
Mahasiswa mampu mengidentifikasi
super key, candidate key dan primary
key dari sebuah table
3.
Mahasiswa mampu mengidentifikasi functional dependency yang ada pada
sebuah tabel, termasuk partial dan transitive FD
4.
Mahasiswa mengenal bentuk normal pertama,
ke dua, ke tiga dan BCNF serta mampu melakukan normalisasi dengan menerapkan
bentuk-bentuk normal tersebut
5.
Mahasiswa mengenal sekilas tentang
bentuk-bentuk normal lain dan memahami konsep denormalisasi
|
||
1.1 Definisi Normalisasi
Normalisasi adalah langkah-langkah sistematis untuk
menjamin bahwa struktur database
memungkinkan untuk general purpose query dan bebas dari insertion,
update dan deletion anomalies yang dapat menyebabkan hilangnya
integritas data (E.F. Codd, 1970)
1.2 Tujuan Normalisasi
Pada dasarnya normalisasi dilakukan untuk
memperbaiki desain tabel yang kurang baik sehingga penyimpanan data menjadi
lebih efisien dan bebas anomali data. Untuk memperjelas pemahaman tentang
proses normalisasi, perhatikan diagram berikut:
Intinya, normalisasi dilakukan terhadap
desain tabel yang sudah ada dengan tujuan untuk meminimalkan redundansi
(pengulangan) data dan menjamin integritas data dengan cara menghidari 3
Anomali Data: Update, Insertion dan Deletion Anomaly.
1.2.1 Update Anomaly
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
Kode_MK
|
Nama_MK
|
SKS
|
Nilai
|
1-01
|
Tukimin
|
TE
|
Elektro
|
TE-001
|
Elektronika
|
3
|
A
|
1-01
|
Tukimin
|
TE
|
Elektro
|
DU-001
|
English
|
2
|
A
|
2-01
|
Jamilah
|
IF
|
Informatika
|
IF-001
|
Algoritma
|
3
|
B
|
2-01
|
Jamilah
|
IF
|
Informatika
|
DU-001
|
English
|
2
|
C
|
2-02
|
Maemunah
|
IF
|
Informatika
|
IF-002
|
Database
|
2
|
A
|
Tabel di atas adalah contoh tabel yang
memiliki desain yang kurang baik. Perhatikan bahwa jika kita ingin meng-update jumlah sks mata kuliah English
dari 2 menjadi 3 sks, maka kita harus mengupdate lebih dari 1 record, yaitu baris 2 dan 4.
Jika hanya salah satu baris saja yang di-update, maka data menjadi tidak
konsisten (ada mata kuliah English dengan 2 sks dan ada mata kuliah English
dengan 3 sks) . Kondisi seperti inilah yang disebut dengan update anomaly.
1.2.2 Insertion Anomaly
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
Kode_MK
|
Nama_MK
|
SKS
|
Nilai
|
1-01
|
Tukimin
|
TE
|
Elektro
|
TE-001
|
Elektronika
|
3
|
A
|
1-01
|
Tukimin
|
TE
|
Elektro
|
DU-001
|
English
|
2
|
A
|
2-01
|
Jamilah
|
IF
|
Informatika
|
IF-001
|
Algoritma
|
3
|
B
|
2-01
|
Jamilah
|
IF
|
Informatika
|
DU-001
|
English
|
2
|
C
|
2-02
|
Maemunah
|
IF
|
Informatika
|
IF-002
|
Database
|
2
|
A
|
Pada
tabel yang sama seperti contoh di atas, terjadi pula insertion anomaly. Misalkan terdapat mahasiswa baru dengan nim 1-02
bernama ‘Zubaedah’ dengan kode jurusan ‘TE’ dan nama jurusan ‘Elektro’.
Data
mahasiswa tersebut tidak dapat dimasukkan ke dalam tabel sebab dia belum
mengambil kuliah apapun (misalnya karena belum melakukan registrasi). Kondisi
inilah yang disebut dengan insertion
anomaly.
1.2.3 Deletion Anomaly
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
Kode_MK
|
Nama_MK
|
SKS
|
Nilai
|
1-01
|
Tukimin
|
TE
|
Elektro
|
TE-001
|
Elektronika
|
3
|
A
|
1-01
|
Tukimin
|
TE
|
Elektro
|
DU-001
|
English
|
2
|
A
|
2-01
|
Jamilah
|
IF
|
Informatika
|
IF-001
|
Algoritma
|
3
|
B
|
2-01
|
Jamilah
|
IF
|
Informatika
|
DU-001
|
English
|
2
|
C
|
IF-002
|
Database
|
2
|
A
|
Pada contoh tabel di atas terjadi deletion anomaly. Perhatikan bahwa jika
kita menghapus data mahasiswa bernama ‘Maemunah’ maka kita harus menghapus data
pada baris ke 5, hal ini akan mengakibatkan kita juga kehilangan data mata
kuliah ‘Database’. Kondisi inilah
yang disebut dengan deletion anomaly.
Selain 3 anomali di atas, ada beberapa
konsep yang mendasari normalisasi. Adapun konsep-konsep penting yang mendasari
normalisasi adalah konsep mengenai super key,
candidate key, primary key, functional dependency dan tentu saja
bentuk-bentuk normal yang menjadi acuan kita dalam melakukan normalisasi
terhadap desain sebuah tabel. Pemahaman terhadap konsep-konsep ini sangat
penting dan akan dibahas di beberapa sub bab berikutnya.
1.3 The Three Keys
Konsep tentang key adalah konsep yang penting untuk memahami keterkaitan antar
atribut data dalam tabel dan akan sangat berguna dalam proses normalisasi.
Dalam setiap tabel, terdapat 3 macam key:
a) Super key
Super key adalah satu atribut atau gabungan atribut (kolom) pada tabel yang
dapat membedakan semua baris secara unik.
b) Candidate key
Candidate key disebut juga dengan minimal
super key, yaitu super key yang
tidak mengandung super key yang lain.
Setiap candidate key pasti merupakan super key, namun tidak semua super key akan menjadi candidate key.
c) Primary key
Primary key adalah salah satu candidate key yang dipilih (dengan berbagai pertimbangan) untuk
digunakan dalam DBMS. Tiap tabel hanya memiliki 1 primary key, namun primary
key tersebut bisa saja dibentuk dari beberapa atribut (kolom).
Untuk memperjelas pemahaman kita terhadap
3 macam key di atas, perhatikan
contohnya pada tabel mata_kuliah di bawah ini:
Kode_MK
|
Nama_MK
|
Semester
|
SKS
|
DU-001
|
English
|
2
|
2
|
DU-002
|
Kalkulus
|
1
|
3
|
IF-001
|
Algoritma
|
1
|
3
|
IF-002
|
Database
|
2
|
3
|
IF-003
|
Artificial Intelligence
|
5
|
2
|
TE-001
|
Elektronika
|
4
|
3
|
Beberapa super key dari tabel di atas adalah:
1.
(kode_mk)
Dari 6 baris data yang ada pada tabel di atas
tak ada satupun yang memiliki kode_mk yang sama.
2.
(nama_mk)
Demikian pula dengan nama_mk,
masing-masing baris data memiliki nama_mk yang unik. Tidak ada satupun baris
data yang memiliki kolom nama_mk dengan nilai yang sama persis.
3.
(kode_mk,nama_mk,semester)
Walaupun beberapa baris data memiliki
kolom semester dengan nilai yang sama (misalnya baris 1&4, baris 2&3)
namun tidak ada satupun baris data yang memiliki kombinasi kode_mk,
nama_mk dan semester yang sama persis.
4.
(kode_mk,nama_mk, sks)
Kombinasi kode_mk, nama_mk dan sks juga
digolongkan sebagai super key
dengan alasan yang kurang lebih sama dengan poin 3.
5. (kode_mk,nama_mk, semester, jml_temu)
Kombinasi kode_mk, nama_mk, semester dan
jml_temu juga digolongkan sebagai super key
dengan alasan yang kurang lebih sama dengan poin 3 dan 4.
Sedangkan yang bukan super key adalah:
1.
(sks)
Perhatikan bahwa kolom sks tidak bisa
membedakan baris data secara unik, contohnya baris data 2,3, 4 dan 6 sama-sama
memiliki kolom sks bernilai 3.
2.
(semester)
Kolom semester juga tidak bersifat unik,
contohnya baris data 1 dan 4 sama-sama memiliki kolom semester bernilai 2
3. (semester, sks)
Kombinasi semester dan sks juga tidak
membedakan tiap baris data secara unik, contohnya baris data ke 2 dan 3
sama-sama memiliki kolom semester bernilai 1 dan sama-sama memiliki kolom sks
bernilai 3
Candidate
key
dari tabel mata_kuliah dipilih dari super
key yang sudah ada. Super key
yang akan menjadi candidate key
adalah super key yang tidak
mengandung super key lain di dalamnya.
Perhatikan 5 super key yang sudah kita peroleh dari analisis sebelumnya:
1.
(kode_mk)
2.
(nama_mk)
3.
(kode_mk,nama_mk,semester)
4.
(kode_mk,nama_mk, sks)
5. (kode_mk,nama_mk, semester, jml_temu)
Super
key
yang hanya teridiri dari satu atribut data pasti akan menjadi candidate key sebab tidak mungkin
mengandung super key yang lain. Oleh
karena itu super key pada poin 1 dan
2 otomatis menjadi candidate key. Super key pada poin 3 tidak menjadi
candidate key sebab dalam kombinasi
(kode_mk, nama_mk, semester) terdapat super
key yang lain yaitu (kode_mk). Dengan demikian, poin 4 dan 5 juga bukan candidate key.
Dari analisis ini, kita memperoleh 2 buah candidate key yaitu (kode_mk) dan
(nama_mk). Salah satu dari beberapa candidate
key ini akan dipilih untuk digunakan dalam DBMS sebagai primary key. Ada beberapa pertimbangan
untuk memilih primary key, di
antaranya adalah jaminan keunikan yang lebih kuat, representasi yang lebih baik
dan lain-lain.
1.4 Functional Dependencies
Functional dependency (FD) atau kebergantungan fungsional adalah constraint atau batasan/ ketentuan antara 2 buah
himpunan atribut pada sebuah tabel.
JIka A dan B adalah himpunan atribut dari
tabel T, kebergantungan fungsional antara A dan B biasanya dinyatakan dalam
notasi notasi A Ã
B. Notasi A Ã
B berarti:
·
A menentukan B
·
B secara fungsional bergantung kepada A.
A Ã B jika memenuhi syarat berikut ini :
Pada sebuah tabel T, jika ada dua baris
data atau lebih dengan nilai atribut A yang sama maka baris-baris data tersebut
pasti akan memiliki nilai atribut B yang sama Namun hal ini tidak berlaku sebaliknya.
Untuk lebih jelasnya perhatikan tabel
berikut ini:
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
Kode_MK
|
Nama_MK
|
SKS
|
Nilai
|
1-01
|
Tukimin
|
TE
|
Elektro
|
TE-001
|
Elektronika
|
3
|
A
|
1-01
|
Tukimin
|
TE
|
Elektro
|
DU-001
|
English
|
2
|
A
|
2-01
|
Jamilah
|
IF
|
Informatika
|
IF-001
|
Algoritma
|
3
|
B
|
2-01
|
Jamilah
|
IF
|
Informatika
|
DU-001
|
English
|
2
|
C
|
2-02
|
Maemunah
|
IF
|
Informatika
|
IF-002
|
Database
|
2
|
A
|
Contoh kebergantungan fungsional yang
terdapat pada tabel di atas:
- NIM Ã Nama_mhs
Untuk setiap baris data, jika NIM = 1-01
pasti Nama_mhs = ‘Tukimin’, walaupun belum tentu semua mahasiswa yang bernama
Tukimin memiliki NIM = 1-01
- NIM Ã Kd_jur
Untuk setiap baris data, jika NIM = 1-01
pasti Kd_jur = ‘TE’, walaupun tidak semua baris data dengan kd_jur ‘TE’
memiliki kolom NIM bernilai 1-01
- NIM Ã Nama_Jur
Untuk setiap baris data dengan kolom NIM
bernilai 1-01 pasti memiliki kolom Nama_Jur = ‘Elektro’, walaupun tidak semua
orang di jurusan Elektro memiliki NIM = 1-01. Demikian pula tidak semua baris
data pada tabel dengan kolom Nama_Jur = ‘Elektro’ memiliki kolom NIM = 1-01
Penulisan kebergantungan fungsional dari 3
poin di atas dapat diringkas menjadi (NIM)
à (nama_mhs, kd_jur, nama_jur)
Dengan demikian, dari tabel tersebut dapat
kita simpulkan beberapa kebergantungan fungsional (FD) sebagai berikut:
• FD1: (nim) Ã (nama_mhs, kd_jur, nama_jur)
• FD2: (kd_jur) Ã (nama_jur)
• FD3: (kode_mk) Ã (nama_mk, sks)
• FD4: (nim,kode_mk) Ã (nilai)
Ada beberapa jenis kebergantungan
fungsional, di antaranya yaitu:
a. Partial Functional dependency
b. Transitive Functional dependency
c.
Multivalued Functional dependency
Ketiganya adalah konsep penting dalam
normalisasi, namun dalam sub bab ini kita hanya akan membahas mengenai Partial Functional dependency dan Transitive Functional dependency.
1.4.1 Partial Funcional Dependency
Partial Functional dependency atau kebergantungan fungsional parsial
terjadi bila:
• B Ã A
• B adalah bagian dari candidate key
Dengan kata lain jika (B,C) adalah candidate
key dan B Ã
A maka A bergantung secara parsial terhadap (B,C) atau (B,C) menentukan A
secara parsial.
Untuk lebih jelasnya perhatikan tabel
berikut ini:
NIM
|
Nama_Mhs
|
Kode_MK
|
Nilai
|
1-01
|
Tukimin
|
TE-001
|
A
|
1-01
|
Tukimin
|
DU-001
|
A
|
2-01
|
Jamilah
|
IF-001
|
B
|
2-01
|
Jamilah
|
DU-001
|
C
|
2-02
|
Maemunah
|
IF-002
|
A
|
Pada tabel di atas perhatikan bahwa:
- Super key : (nim,kode_mk), (nim,nama_mhs,kode_mk) dan (nim,nama_mhs,kode_mk,nilai)
- Dari super key yang sudah diperoleh pada poin 1, maka dipilih super key yang akan menjadi candidate key yaitu (nim,kode_mk)
- FD: (nim) Ã (nama_mhs)
Dari
analisis poin 2 dan 3 maka dapat disimpulkan bahwa terjadi kebergantungan
fungsional parsial dimana (nama_mhs) bergantung kepada (nim,kode_mk) secara
parsial atau dapat juga dikatakan bahwa (nim,kode_mk) menentukan (nama_mhs)
secara parsial.
1.4.2 Transitive Functional dependency
Transitive Functional dependency atau
kebergantungan fungsional transitif terjadi jika:
- A Ã B
- B Ã C
Jika A Ã B dan B Ã C maka A Ã C. Dengan kata
lain A bergantung secara transitif terhadap C melalui B atau A menentukan C
secara transitif melalui B.
Untuk lebih
jelasnya perhatikan contoh tabel berikut ini:
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
1-01
|
Tukimin
|
TE
|
Elektro
|
1-01
|
Tukimin
|
TE
|
Elektro
|
2-01
|
Jamilah
|
IF
|
Informatika
|
2-01
|
Jamilah
|
IF
|
Informatika
|
2-02
|
Maemunah
|
IF
|
Informatika
|
FD1: (nim) Ã
(nama_mhs, kd_jur, nama_jur)
FD2: (kd_jur) Ã (nama_jur)
Dengan
demikian dapat disimpulkan bahwa (nama_jur) bergantung secara transitif
terhadap (nim) melalui (kd_jur) atau
dapat juga dikatakan bahwa (nim) Ã (nama_jur) secara transitif melalui
(kd_jur).
1.5 Bentuk Normal dan Langkah-Langkah Normalisasi
Bentuk Normal adalah sekumpulan kriteria yang harus
dipenuhi oleh sebuah desain tabel untuk mencapai tingkat/level bentuk normal
tertentu. Parameter yang
biasanya digunakan dalam menentukan kriteria bentuk normal adalah Functional
dependency & The Three Keys.
Masing-masing
bentuk normal memiliki kriteria dan level tertentu yang tidak mungkin dicapai
tanpa memenuhi kriteria bentuk nomal level yang berada di bawahnya. Makin tinggi level bentuk normal yang
dicapai maka kualitas desain tabel tersebut dinyatakan makin baik dan semakin
kecil peluang terjadinya anomali dan redundansi data.
Normalisasi dilakukan dengan cara
menerapkan Bentuk-Bentuk Normal secara bertahap dari level terendah sampai
level yang dikehendaki. Walaupun ada beberapa bentuk normal namun jika desain
tabel tertentu sudah memenuhi kriteria 3rd NF atau BCNF maka desain
tabel itu biasanya dianggap sudah ‘cukup normal’.
1.5.1 Bentuk Normal Pertama (1st Normal Form)
Bentuk normal pertama atau First Normal Form (1st NF)
adalah bentuk normal yang memiliki level terendah.
Kriteria 1st NF:
• Tidak ada atribut (kolom) pada tabel yang bersifat multi-value
Sebuah atribut disebut bersifat multivalue jika dalam sebuah baris data
pada kolom tersbut terdapat lebih dari satu nilai. Misalnya kolom telepon yang
berisi ‘0813xx, 022xxx’ dan seterusnya.
• Tidak memiliki lebih dari satu atribut dengn domain yang sama
Sebuah tabel dikatakan memiliki lebih dari
satu atribut dengan domain yang sama jika pada tabel tersebut terdapat lebih dari
satu kolom yang digunakan untuk menyimpan data yang jenisnya sama. Misalnya
kolom telepon1, telepon2, telepon3 dan seterusnya.
Untuk lebih jelasnya perhatikan 2 versi
contoh tabel T berikut ini:
NIM
|
Nama_Mhs
|
Telp_1
|
Telp_2
|
Kd_Jur
|
Nama_Jur
|
Kode_MK
|
Nama_MK
|
SKS
|
Nilai
|
1-01
|
Tukimin
|
0813xx
|
022xxx
|
TE
|
Elektro
|
TE-001
|
Elektronika
|
3
|
A
|
2-01
|
Jamilah
|
0812xx
|
021xxx
|
IF
|
Informatika
|
IF-001
|
Algoritma
|
3
|
B
|
2-02
|
Maemunah
|
0852xx
|
031xxx
|
IF
|
Informatika
|
IF-002
|
Database
|
2
|
A
|
Tabel T versi pertama ini memiliki 2
atribut dengan domain yang sama yaitu kolom telp_1 dan telp_2. Hal ini
menunjukkan bahwa tabel T versi pertama ini belum memenuhi syarat 1st
NF.
NIM
|
Nama_Mhs
|
Telepon
|
Kd_Jur
|
Nama_Jur
|
Kode_MK
|
Nama_MK
|
SKS
|
Nilai
|
1-01
|
Tukimin
|
0813xx, 022xxx
|
TE
|
Elektro
|
TE-001
|
Elektronika
|
3
|
A
|
2-01
|
Jamilah
|
0812xx, 021xxx
|
IF
|
Informatika
|
IF-001
|
Algoritma
|
3
|
B
|
2-02
|
Maemunah
|
0852xx, 031xxx
|
IF
|
Informatika
|
IF-002
|
Database
|
2
|
A
|
Tabel T versi ke dua ini juga belum
memenuhi sayarat 1st NF karena kolom telepon bersifat multivalue.
Solusi agar tabel T memenuhi syarat 1st
NF adalah dengan melakukan pemecahan tabel atau dekomposisi tabel. Namun perlu
diingat, dekomposisi tabel harus dilakukan dengan cermat agar data tetap
konsisten (perubahan hanya terjadi pada struktur tabel tapi tidak terjadi
perubahan pada data)
Perhatikan bahwa (nim) Ã (telepon). Dengan demikian, kita dapat
memecah tabel T menjadi tabel T-1 dan tabel T-2 berikut ini:
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
Kode_MK
|
Nama_MK
|
SKS
|
Nilai
|
1-01
|
Tukimin
|
TE
|
Elektro
|
TE-001
|
Elektronika
|
3
|
A
|
2-01
|
Jamilah
|
IF
|
Informatika
|
IF-001
|
Algoritma
|
3
|
B
|
2-02
|
Maemunah
|
IF
|
Informatika
|
IF-002
|
Database
|
2
|
A
|
Tabel 4‑11 Contoh Tabel T-2
NIM
|
Telepon
|
1-01
|
0813xx
|
1-01
|
022xxx
|
2-01
|
0812xx
|
2-01
|
021xxx
|
2-02
|
0852xx
|
2-02
|
031xxx
|
Baik Tabel T1 maupun tabel T2 tidak
memiliki atribut bersifat multivalue.
Tabel T1 dan T2 juga tidak memiliki lebih dari satu atribut dengan domain yang
sama. Dengan demikian dapat disimpulkan bahwa tabel T1 dan T2 telah memenuhi
syarat 1st NF dan siap untuk diperiksa apakah memenuhi syarat bentuk
normal level berikutnya (2nd NF)
1.5.2 Bentuk Normal Ke Dua (2nd Normal Form)
Kriteria 2nd NF:
• Memenuhi 1st NF
Desain tabel yang tidak memenuhi syarat 1st
NF sudah pasti tidak akan memenuhi syarat 2nd NF
• Tidak ada Partial Functional
dependency
Partial Functional dependency terjadi bila (B,C) adalah candidate key dan B Ã A
Untuk lebih jelasnya perhatikan tabel
T-1hasil tahap sebelumnya:
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
Kode_MK
|
Nama_MK
|
SKS
|
Nilai
|
1-01
|
Tukimin
|
TE
|
Elektro
|
TE-001
|
Elektronika
|
3
|
A
|
2-01
|
Jamilah
|
IF
|
Informatika
|
IF-001
|
Algoritma
|
3
|
B
|
2-02
|
Maemunah
|
IF
|
Informatika
|
IF-002
|
Database
|
2
|
A
|
Perhatikan bahwa:
1.
(nim, kode_mk) adalah candidate key
2.
FD1: (nim) Ã (nama_mhs, kd_jur, nama_jur)
3.
FD2: (kode_mk) Ã (nama_mk, sks)
4.
FD3: (nim,kode_mk) Ã nilai
Berarti Terjadi Partial Functional dependency:
• FD 1: (nim,kode_mk) Ã (nama_mhs,kd_jur,nama_jur) secara parsial
• FD 2: (nim,kode_mk) Ã (nama_mk,sks) secara parsial
Walaupun tabel T-1 telah memenuhi syarat 1st
NF namun karena terjadi partial functional
dependency maka tabel T-1 belum memenuhi syarat 2nd NF.
Solusinya adalah dengan melakukan
dekomposisi terhadap tabel T-1 dengan tetap menjaga agar datanya tetap
konsisten. Hal ini dapat dilakukan dengan melakukan dekomposisi tabel sesuai
FD1, FD2 dan FD3 yang telah kita analisis sebelumnya. Adapun hasil dekomposisi
dari tabel T-1 adalah 3 tabel berikut ini:
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
1-01
|
Tukimin
|
TE
|
Elektro
|
2-01
|
Jamilah
|
IF
|
Informatika
|
2-02
|
Maemunah
|
IF
|
Informatika
|
Kode_MK
|
Nama_MK
|
SKS
|
TE-001
|
Elektronika
|
3
|
DU-001
|
English
|
2
|
IF-001
|
Algoritma
|
3
|
IF-002
|
Database
|
2
|
NIM
|
Kode_MK
|
Nilai
|
1-01
|
TE-001
|
A
|
1-01
|
DU-001
|
A
|
2-01
|
IF-001
|
B
|
2-01
|
DU-001
|
C
|
2-02
|
IF-002
|
A
|
Ketiga
tabel hasil dekomposisi tersebut sudah tidak mengalami partial functional dependency. Dengan demikian ketiga tabel
tersebut telah memenuhi syarat 2nd
NF dan siap untuk diperiksa apakah memenuhi syarat bentuk normal level
berikutnya (3rd NF).
Adapun Tabel T-2 (hasil dekomposisi pada
tahap 1st NF) juga tidak mengalami partial functional dependency sehingga sudah memenuhi 2nd
NF, tidak perlu didekomposisi lagi dan dapat langsung diperiksa apakah memenuhi
3rd NF bersama-sama dengan tabel T-1-1, T-1-2 dan T-1-3.
1.5.3 Bentuk Normal Ke Tiga (3rd Normal Form)
Umumnya jika sebuah tabel telah memenuhi syarat
bentuk normal ke tiga (3rd NF) maka tabel tersebut sudah dianggap
‘cukup normal’. Bentuk normal ke 3 adalah bentuk normal yang biasanya menjadi
syarat minimum bagi sebuah desan
tabel walaupun akan lebih baik jika juga memenuhi BCNF.
Kriteria 3rd NF:
• Memenuhi 2nd NF
Desain tabel yang tidak memenuhi syarat 2nd
NF sudah pasti tidak akan memenuhi syarat 3rd NF
• Tidak ada Transitive Functional
dependency
Transitive functional dependency terjadi bila AÃ B dan BÃ C
Untuk lebih jelasnya perhatikan tabel
T-1-1 dari tahap sebelumnya:
Tabel 4‑16 Contoh tabel T-1-1
NIM
|
Nama_Mhs
|
Kd_Jur
|
Nama_Jur
|
1-01
|
Tukimin
|
TE
|
Elektro
|
2-01
|
Jamilah
|
IF
|
Informatika
|
2-02
|
Maemunah
|
IF
|
Informatika
|
Perhatikan bahwa:
FD1: (nim) Ã (nama_mhs, kd_jur, nama_jur)
FD2: (kd_jur) Ã (nama_jur)
Berarti Terjadi Transitive FD:
(nim) Ã (nama_jur) secara transitif melalui
(kd_jur)
Walaupun tabel T-1-1 telah memenuhi syarat
2nd NF namun karena terjadi transitive
functional dependency maka tabel T1 belum memenuhi syarat 3rd
NF. Solusinya adalah dengan melakukan dekomposisi terhadap tabel T-1-1 dengan
tetap menjaga agar datanya tetap konsisten sesuai FD1dan FD2. Adapun hasil
dekomposisi dari tabel T-1-1 adalah 2 tabel berikut ini:
NIM
|
Nama_Mhs
|
Kd_Jur
|
1-01
|
Tukimin
|
TE
|
2-01
|
Jamilah
|
IF
|
2-02
|
Maemunah
|
IF
|
Kd_Jur
|
Nama_Jur
|
TE
|
Elektro
|
IF
|
Informatika
|
IF
|
Informatika
|
1.5.4 Bentuk Normal Boyce Codd (BC Normal Form)
Boyce Codd Normal Form atau bentuk normal Boyce-Codd adalah
bentuk normal yang levelnya di atas 3rd NF. Kriteria BCNF:
• Memenuhi 3rd NF
Desain tabel yang tidak memenuhi syarat 3rd
NF sudah pasti tidak akan memenuhi syarat BCNF
• Untuk semua FD yang terdapat di tabel, ruas kiri dari FD tersebut
adalah super key
Jika ada satu saja FD pada tabel dimana
ruas kirinya bukan super key maka
desain tabel tersebut belum memenuhi syarat BCNF. Solusinya adalah dengan
melakukan dekomposisi tabel dan tetap mempertahankan konsistensi data seperti
beberapa contoh pada sub bab sebelumnya
Jarang ada kasus dimana sebuah tabel
memenuhi 3rd NF tapi tidak memenuhi BCNF. Umumnya sebuah tabel
dikategorikan sudah ‘cukup normal’ jika sudah memenuhi kriteria BCNF. Jika
tidak memungkinkan untuk memenuhi kriteria BCNF, maka 3rd NF juga
sudah dianggap cukup memadai.
1.5.5 Bentuk-Bentuk Normal Lainnya
Selain bentuk-bentuk normal yang sudah diperkenalkan
pada beberapa sub bab sebelumnya, masih ada beberapa bentuk-bentuk normal lain.
Beberapa diantaranya adalah sebagai berikut:
1. Bentuk Normal ke-4 (4th NF)
diperkenalkan oleh Ronald Fagin pada tahun
1977
2. Bentuk Normal ke-5 (5th NF)
diperkenalkan oleh Ronald Fagin pada tahun
1979
3. Domain/Key Normal Form
(DKNF)
diperkenalkan oleh Ronald Fagin pada tahun
1981
4. Bentuk Normal ke-6 (6th NF)
diperkenalkan oleh Date, Darwen dan
Lorentzos pada tahun 2002
1.6 Denormalisasi
Denormalisasi adalah proses
menggandakan data secara sengaja (sehingga menyebabkan redundansi data) untuk
meningkatkan performa database, untuk
meningkatkan kecepatan akses data atau memperkecil query cost.
Yang
perlu diingat tentang denormalisasi adalah bahwa denormalisasi tidak sama dengan tidak melakukan
normalisasi. Denormalisasi dilakukan setelah
tabel dalam kondisi ‘cukup normal’ (mencapai level bentuk normal yang
dikehendaki).
Salah
satu contoh teknik Denormalisasi adalah Materialized View pada DBMS Oracle. Materialized
view adalah teknik menggandakan data dengan cara membuat tabel semu berupa
view fisik (yang benar-benar dituliskan di disk, bukan sebatas di memory). Materialized view biasanya dibuat dari hasil join beberapa tabel yang sering diakses tapi jarang diupdate.
Materialized view akan menyebabkan
redundansi data, namun sebagai imbalannya kecepatan akses data meningkat
drastis sebab data dapat langsung diakses melalui materialized view tanpa harus menunggu query menyelesaikan operasi join
dari beberapa tabel.
Ada beberapa
alasan melakukan denormalisasi:
1. Mempercepat
proses query dengan cara meminimalkan
cost yang disebabkan oleh operasi join antar tabel
2. Untuk
keperluan Online Analytical Process
(OLAP)
3. Dan
lain-lain
Adapun
konsekuensi denormalisasi adalah sebagai berikut:
1. Perlu
ruang ekstra untuk penyimpanan data
2. Memperlambat
pada saat proses insert, update dan delete sebab proses-proses tersebut harus
dilakukan terhadap data yang redundant (ganda)
Dengan demikian
dapat disimpulkan bahwa denormalisasi harus dilakukan dengan bijak sebab
walaupun memiliki beberapa keuntungan namun juga memiliki konsekuensi yang
patut diperhitungkan.
Rangkuman
|
1.
Normalisasi merupakan serangkaian
langkah sistematis yang dilakukan terhadap desain tabel dan bertujuan untuk
menghindari redundansi dan anomaly data sekaligus mengefisienkan penyimpanan
data.
2.
Tiga macam anomaly data: update, insertion dan deletion anomaly
3.
Super key adalah sebuah atribut atau
sekumpulan atribut yang dapat membedakan setiap baris data dalam tabel secara
unik
4.
Candidate key adalah
minimal super key yang tidak mengandung super key yang lain
5.
Primary key adalah candidate key yang dipilih untuk
diimplementasikan pada DBMS
6.
Setiap primary key pasti merupakan candidate key, setiap candidate key pasti merupakan super key. Hal ini tidak berlaku
sebaliknya.
7.
A Ã B jika terpenuhi syarat bahwa untuk setiap baris data di tabel T, jika ada
pasangan baris data pada kolom A memiliki nilai yang sama maka dijamin kolom B
pada baris-baris tersebut juga akan memiliki nilai yang sama, namun tidak harus
sebaliknya.
8.
Partial Functional dependency terjadi bila
sebuah atribut bergantung pada sebagian dari candidate key
9.
Transitive Functional dependency terjadi bila sebuah
atribut bergantung pada key melalui
atribut lain
10.
Normalisasi
dilakukan secara bertahap, yaitu dengan menerapkan bentuk-bentuk normal dari
mulai level terendah sampai mencapai level yang dikehendaki.
11.
Syarat 1st NF:
tidak ada atribut multivalue dan
tidak ada lebih dari satu atribut dengan
domain yang sama
12.
Syarat 2nd NF:
memenuhi syarat 1st NF dan tidak mengalami partial functional dependency
13.
Syarat 3rd NF:
memenuhi syarat 2nd NF dan tidak mengalami transitive functional dependency
14.
Syarat BCNF: memenuhi
syarat 3rd NF dan ruas kiri dari setiap functional
dependency-nya adalah super key
15.
Denormalisasi
tidak sama dengan tidak melakukan normalisasi, tujuannya adalah untuk
meningkatkan performa database
sebagai imbalan dari munculnya redundansi (pengulangan data) pada database.
Kuis Benar Salah
|
1.
Normalisasi dilakukan secara bertahap
2.
Setiap super key pasti
bisa membedakan baris-baris data dalam tabel secara unik
3.
Dalam sebuah tabel minimal ada satu candidate key
4.
Primary key dalam sebuah tabel bisa ada lebih dari
satu
5.
Primary key dalam sebuah tabel bisa terdiri dari
beberapa atribut
6.
Jika sebuah tabel mengalami transitive
functional dependency pasti tabel tersebut tidak memenuhi syarat 2nd
NF
7.
Jika sebuah tabel mengalami transitive
functional dependency pasti tabel tersebut tidak memenuhi syarat BCNF
8.
Desain tabel yang sudah memenuhi 2nd
NF pasti tidak memiliki atribut multivalue
9.
Desain tabel yang sudah memenuhi
syarat BCNF pasti tidak mengalami partial
functional dependency tapi masih mungkin mengalami transitive functional dependency
10.
Denormalisasi adalah membuat tabel menjadi ‘tidak normal’
Pilihan Ganda
|
|||||||
Petunjuk:
Pilihlah jawaban yang paling tepat!
1.
Normalisasi
bertujuan untuk _____
A.
Membuat desain
tabel menjadi lebih efisien
B.
Menghidari
update dan insertion anomaly
C.
Meminimalkan
redundansi data
D.
Menghindari
deletion anomaly
E.
Semua benar
2.
Atribut atau
sekumpulan atribut yang dapat membedakan setiap baris data dalam tabel secara
unik disebut _____
A.
Super key
B.
Candidate key
C.
Primary key
D.
Functional dependency
E.
Tidak ada
jawaban yang benar
3.
Jika diketahui
FD1: (A,B) Ã (C) dan FD2: (C)Ã (D,E) maka dapat disimpulkan bahwa _____
A.
Terjadi
transitive functional dependency
B.
Tabel tersebut
tidak memenuhi syarat 3rd NF
C.
(A,B) Ã (C,D)
D.
Pilihan A dan B
benar
E.
Pilihan A, B
dan C benar
4.
Syarat 2nd NF
adalah _____
A.
Tabel harus
memiliki lebih dari 1 candidate key
B.
Tidak boleh ada
atribut atau kolom yang bergantung secara fungsional pada sebagian dari candidate key
C.
Tabel harus
memiliki primary key
D.
Tidak terjadi
transitive functional dependency
E.
Tidak ada
jawaban yang benar
5.
Syarat 3nd NF
adalah _____
A.
Tabel harus
bebas dari partial functional
dependency
B.
Tabel harus
memiliki candidate key
C.
Tidak terdapat multivalue atribut
D.
Memenuhi syarat
BCNF
E.
Memenuhi syarat
2nd NF dan bebas dari transitive functional
dependency
6.
Pernyataan yang
benar tentang primary key adalah
_____
A.
Setiap primary key pasti merupakan super key
B.
Setiap primary key pasti merupakan candidate key
C.
Primary key dalam
sebuah tabel boleh lebih dari satu
D.
Primary key boleh
terdiri dari sekumpulan atribut
E.
Semua jawaban
benar
7.
Atribut atau
sekumpulan atribut yang tidak dapat membedakan setiap baris data dalam tabel
secara unik disebut _____
A.
Super key
B.
Candidate key
C.
Primary key
D.
Functional dependency
E.
Non key
8.
Jika sebuah
tabel T dipastikan telah memenuhi syarat BCNF maka dapat disimpulkan bahwa
_____
A.
Tabel T pasti
memenuhi syarat 1st NF
B.
Tabel T pasti
bebas dari partial functional dependecy
C.
Tabel T pasti
bebas dari transitive functional dependency
D.
Semua ruas kiri
FD pada tabel T pasti merupakan super key
E.
Semua benar
9.
Salah satu
contoh denormalisasi adalah _____
A.
View
B.
Sequence
C.
Materialized
View
D.
Index
E.
Tidak ada
jawaban yang benar
10.
Dampak
penerapan denormalisasi diantaranya _____
A.
Penyimpanan
data menjadi lebih boros
B.
Performa database menjadi makin lambat
C.
Kecepatan query menurun karena datanya redundan
D.
Tabel menjadi
mengalami partial functional dependency
E.
Tidak ada
jawaban yang benar
|
|||||||
Latihan
|
|||||||
Lakukan normalisasi untuk tabel
berikut ini sampai mencapai BCNF
Tgl_Kembali
|
1-Mar-09
|
23-Feb-09
|
14-Feb-09
|
23-Feb-09
|
1-Mar-09
|
23-Feb-09
|
23-Feb-09
|
Tgl_Pinjam
|
23-Feb-09
|
31-Jan-09
|
31-Jan-09
|
14-Feb-09
|
23-Feb-09
|
31-Jan-09
|
31-Jan-09
|
No_Rak
|
R-01
|
R-02
|
R-01
|
R-02
|
R-02
|
R-01
|
R-01
|
Jns_Buku
|
Fiksi
|
Non Fiksi
|
Fiksi
|
Non Fiksi
|
Non Fiksi
|
Fiksi
|
Fiksi
|
Jdl_Buku
|
Buku Ini
|
Buku Itu
|
Buku Anu
|
Buku Itu
|
Buku Itu
|
Buku Ini
|
Buku Anu
|
Kd_Buku
|
B-01
|
B-02
|
B-03
|
B-02
|
B-02
|
B-01
|
B-03
|
Nama_Ang
|
Jamal
|
Jamal
|
Jawilem
|
Jawilem
|
Jawilem
|
Juminten
|
Juminten
|
Id_Ang
|
A-01
|
A-01
|
A-02
|
A-02
|
A-02
|
A-03
|
A-03
|
sumber : bapak yusril
1 comments:
Terima kasih atas informasinya.. ini sangat membantu (y) :)
Post a Comment