modul 13 - fd dan normalisasi
Post on 24-Oct-2015
68 Views
Preview:
DESCRIPTION
TRANSCRIPT
Normalisasi
Mata Ajar Basis Data
Content Development GDLN Batch 2 2
Tujuan Pemelajaran
Setelah mengikuti pemelajaran pada topik ini, Anda diharapkan dapat merancang skema basis data yang baik, mencapai bentuk normal 3NF atau BCNF.
Content Development GDLN Batch 2 3
Outline
1. Panduan Informal dalam MerancangBasis Data Relasional
1. Panduan Informal dalam MerancangBasis Data Relasional
2. Functional Dependency2. Functional Dependency
3. Normalisasi Berdasarkan Primary Key3. Normalisasi Berdasarkan Primary Key
4. General Normal Form4. General Normal Form
5. Boyce Codd Normal Form5. Boyce Codd Normal Form
Content Development GDLN Batch 2 4
Panduan Informal dalam Merancang Basis Data Relasional
Content Development GDLN Batch 2 5
Panduan Merancang Basis Data Relasional
Skema basis data dapat dilihat dari dua level: – pengguna (logical level) – penyimpanan data di komputer (storage
level)
Perancangan di sini berfokus pada skema basis data yang tersimpan di komputer (base relations)
Bagaimana kriteria base relations yang baik?
Content Development GDLN Batch 2 6
Panduan Informal
Panduan secara umum berkaitan dengan: Semantik atribut-atribut relasi Data yang berulang dan kaitannya
dengan update anomali Nilai null Spurious tuples
Content Development GDLN Batch 2 7
Panduan 1: Semantik Atribut-Atribut Relasi Panduan 1: Setiap tuple pada
relasi seharusnya merepresentasikan satu entity atau relationship instance. Skema perlu dirancang agar mudah dijelaskan relasi demi relasi. Semantik dari atribut sebaiknya mudah diinterpretasikan
Atribut-atribut dari entity yang berbeda-beda seharusnya tidak bergabung dalam satu relasi
Hanya foreign key yang digunakan untuk mengacu ke relasi lain
Atribut-atribut entity dan relationship sebaiknya dipisahkan
SSN Name BirthData Sex Address DNo DName DMgrSSN
SSN Name BirthData Sex Address DNo
DNo DName DMgrSSN
X
Content Development GDLN Batch 2 8
Panduan 2: Data Berulang dan Update Anomali
Informasi yang disimpan berulang (redundant) menyebabkan pemborosan ruang penyimpanan dan berpotensi menyebabkan update anomali
Update anomali meliputi: – Insertion anomali– Deletion anomali– Modification anomali
Panduan 2: Rancanglah skema yang bebas dari anomali. Jika terpaksa ada anomali, perlu dicatat dan ditangani oleh aplikasi
Content Development GDLN Batch 2 9
Contoh Update AnomaliPada relation:
EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours) Modification anomali:
Mengubah nama proyek bernomor P1 dari “Billing” ke “Customer Accounting” penyebabkan modifikasi harus dilakukan pada 100 pegawai yang bekerja pada proyek P1
Insert anomali: Tidak dapat menyisipkan sebuah proyek baru kecuali sudah ada pegawai yang di tunjuk menangani proyek tersebut, dan sebaliknya tidak dapat menyisipkan pegawai baru kecuali sudah ada proyek yang diberikan kepada pegawai tersebut
Delete anomali:Jika sebuah proyek dihapus, maka harus menghapus semua pegawai yang bekerja pada proyek tersebutJika pegawai bekerja seorang diri pada suatu proyek dan pegawai tersebut re-sign, maka data mengenai proyek tersebut juga harus dihapus
Content Development GDLN Batch 2 10
Contoh Update Anomali
Relation EMP_DEPT berasal dari natural join antara 2 buah relation: EMPLOYEE dan DEPARTMENT.
Relation EMP_PROJ berasal dari natural join antara 2 buah relation: EMPLOYEE dan PROJECT.
Keduanya mengandung redundancy (data yang berulang) dan juga mengandung update anomali
Content Development GDLN Batch 2 11
Panduan 3: Nilai NULL Panduan 3: Relations harus dirancang
agar nilai null yang ada pada baris-barisnya sesedikit mungkin
Attributes yang bernilai null seringkali dapat ditempatkan pada relations terpisah.
Content Development GDLN Batch 2 12
Panduan 4: Spurios Tuples Dalam merancang, kadang-kadang kita
melakukan dekomposisi relasi maupun penggabungan beberapa relasi. Ada 2 hal yang perlu diperhatikan:– Apakah dekomposisi (pemecahan) sebuah relasi
menjadi dua/lebih relasi baru akan menyebabkan adanya data yang hilang?
– Apakah penggabungan dua/lebih relasi menjadi sebuah relation baru akan menghasilkan kelebihan data (yang sebenarya tidak ada)?
Panduan 4: – Relasi harus dirancang agar memenuhi lossless join
condition dan – tidak ada spurious tuples yang dihasilkan oleh natural
join antar relasi
Content Development GDLN Batch 2 13
Contoh: Data yang Hilang Relasi RS berasal dari natural join antara relasi R
dan relasi S. Apa yang hilang dalam proses join ini?
R = (A, B, C) S = (D, C)
b2b2b4
c1c1c2
A B C
c1c2c2c3
d1d2d4d5
D C
a1a2a3a3
a1a2a3
b2b2b4b4
c1c1c2c2
d1d1d2d4
A B C D
RS(A, B, C, D)
Kehilangan data (d5, c3) setelah join R & S
Content Development GDLN Batch 2 14
Contoh: Spurious Tuples Spurious tuples terjadi setelah proses join R1 dan R2
a1a2a3a4
b1b2b1b2
c1c2c1c2
d1d1d2d3
A B C D
R(A, B, C, D) R1(B, D)
B C
b1b2b1b2
d1d1d2d3
D
d1d1d2d3
A
a1a2a3a4
R2(A, D)
a1a2a1a2a3a4
b1b1b2b2b1b2
c1c2c2c2c1c2
d1d1d1d1d2d3
A B C D
R1 and R2 Join
Content Development GDLN Batch 2 15
Functional Dependency
Content Development GDLN Batch 2 16
Pengertian Functional Dependency Functional dependency (disingkat FD) merupakan
batasan yang berasal dari makna attributes dan keterhubungan antar attributes
Adanya functional dependency dari X ke Y menandakan bahwa nilai attribute X menentukan secara unik nilai attribute Y– Dituliskan sebagai X Y– Dapat dibaca sebagai:
• X menentukan Y atau • Y ditentukan oleh X atau• Ada dependensi fungsional dari X ke Y
FD diperoleh dari fakta yang ada (diperoleh pada tahap analisis sistem)
Content Development GDLN Batch 2 17
Contoh Functional Dependency
Relation instance TEACH di atas berpotensi memiliki functional dependency TEXT COURSE
Tidak terdapat FD TEACHER COURSE Bagaimana jika ada baris baru yang ditambakan: “James,
Web Databases, Al-Nour”? FD harus berlaku untuk semua baris pada relasi. Untuk
menentukan FD harus memahami semantik data, mempertimbangkan instance yang ada sekarang dan yang akan ada di masa mendatang
Content Development GDLN Batch 2 18
Contoh Functional Dependency
Pada relasi EMP_PROJ terdapat 3 FD: {SSN, PNUMBER} HOURS SSN ENAME PNUMBER PNAME, PLOCATION
Content Development GDLN Batch 2 19
Inrefence Rule untuk FD Diberikan sekumpulan FD F, kita dapat
menurunkan FD-FD yang lain dari F Contoh:
F = {SSN {EName, BDate, Address, DNumber}, {SSN, ProjNo} Hours }
Apa FD yang memiliki makna sama dengan F?
SSN Ename SSN Bdate SSN Address SSN Dnumber SSN SSN {SSN, ProjNo} Hours
Content Development GDLN Batch 2 20
Inrefence Rule untuk FD
Amstrong’s Inference Rule1. Reflective (IR1): If X Y, then X Y.
2. Augmentation (IR2): If {X Y} then XZ YZ.
3. Transitive (IR3): If {X Y, Y Z} then X Z.
Derived Inference Rule4. Decomposition: If {X YZ} then X Y.
5. Additive (Union): If {X Y, X Z} then X YZ.
6. Pseudotransitive: If {X Y, WY Z} then WX Z.
Content Development GDLN Batch 2 21
Closure (penutup) dari himpunan functional dependency F adalah himpunan F+ yang beranggota semua FD yang dapat diturunkan dari F
Closure dari himpunan attribute X yang berkaitan dengan F adalah himpunan X+ yang beranggota semua attribute yang ditentukan secara fungsional oleh X
X+ dapat dicari dengan menerapkan secara berulang IR1, IR2, IR3 dengan menggunakan FD yang ada pada F
Inrefence Rule untuk FD
Content Development GDLN Batch 2 22
Diberikan himpunan FD, setiap X pada sisi kiri FD, maka closure X+ adalah attributes yang ditentukan oleh X.
Algorithm 10.1 Determining X+, Closure of X under F
X+ := X;
repeat
1. oldX+ := X+ ;
2. for each FD Y Z in F do
3. if X+ Y then X+ := X+ Z;
until (X+ = old X+ );
Algoritma untuk menentukan closure dari FD
Content Development GDLN Batch 2 23
Diberikan F = {SSN ENAME, PNUMBER {PNAME, PLOCATION}, {SSN, PNUMBER} HOURS }
{SSN}+ = {SSN, ENAME}{PNUMBER}+ = {PNUMBER, PNAME, PLOCATION } {SSN, PNUMBER}+ = {SSN, PNUMBER, ENAME,
PNAME, PLOCATION, HOURS}
Contoh: Menghitung{SSN, PNUMBER}+
Apakah {SSN, PNUMBER} SSN? Ya – Tambahkan ENAME
Apakah {SSN, PNUMBER, ENAME} PNUMBER? Ya – Tambahkan PNAME, PLOCATION
Apakah {SSN, PNUMBER, ENAME, PNAME, PLOCATION} {SSN, PNUMBER}?
Ya – Tambahkan HOURS
Contoh Penerapan Algoritma 10.1
Content Development GDLN Batch 2 24
Carilah {DNUMBER}+
Apakah {DNUMBER} SSN ? Tidak – Lanjut ke FD berikutnya
Apakah {DNUMBER} DNUMBER ? Ya – Tambahkan DNAME, DMGRSSN
Jadi {DNUMBER}+ = {DNUMBER, DNAME, DMGRSSN}
Carilah {SSN}+
Akan didapatkan {SSN}+ ={SSN, ENAME, BDATE, ADDRESS, DNUMBER, DNAME, DMGRSSN}
Diketahui G = {SSN {ENAME, BDATE, ADDRESS, DNUMBER}, DNUMBER {DNAME, DMGRSSN} }
Contoh Penerapan Algoritma 10.1
Content Development GDLN Batch 2 25
Menginterpretasikan Himpunan Closure
Apa yang ekuivalen dengan {SSN}+ = {SSN, ENAME}? SSN ENAME, SSN SSN, SSN SSN, ENAME
Bagaimana dengan {PNUMBER}+ ={PNUMBER,PNAME,PLOCATION} ?
PNUMBER PNAME PNUMBER PLOCATION PNUMBER PNUMBER PNUMBER {PNAME, PLOCATION} PNUMBER {PNUMBER, PLOCATION} PNUMBER {PNAME, PNUMBER} PNUMBER {PNUMBER, PNAME, PLOCATION}
Bagaimana dengan {SSN, PNUMBER}+ = {SSN, PNUMBER, ENAME, PNAME, PLOCATION, HOURS} ?
Content Development GDLN Batch 2 26
Normalisasi Berdasarkan Primary Key
Content Development GDLN Batch 2 27
Normalisasi
Normalisasi (Normalization):– Proses dekomposisi relasi yang masih
“buruk” dengan memecah atribut-atributnya untuk membentuk beberapa relasi
Bentuk Normal (Normal Form)– Kondisi (dengan menggunakan FD dan
key) yang menentukan apakah suatu skema relasi memenuhi kriteria tertentu
Content Development GDLN Batch 2 28
Bentuk Normal Ada beberapa bentuk normal berdasarkan sejumlah
kriteria: – Primary keys (1NF, 2NF, 3NF)– All Candidate Keys ( 2NF, 3NF, BCNF)– Multivalued Dependencies (4NF)– Join Dependencies (5NF)
5 NF4NF
3NF
2NF
1NF
Content Development GDLN Batch 2 29
Penggunaan Bentuk Normal Normalisasi perlu dilakukan agar rancangan basis
data yang dihasilkan berkualitas baik dan memenuhi sifat yang diinginkan
Normalisasi dalam praktiknya sulit dilakukan jika batasan-batasan yang menjadi dasar normalisasi sulit dimengerti atau sulit dideteksi
Perancang basis data tidak perlu melakukan normalisasi sampai bentuk tertinggi– Normalisasi biasanya dilakukan sampai mencapai
3NF atau BCNF Denormalisasi: kebalikan dari proses normalisasi,
yakni menggabungkan beberapa relasi, membawa ke bentuk normal yang lebih rendah
Content Development GDLN Batch 2 30
Key Attibutes
Superkey dari relasi R: himpunan attribute dari R yang dapat membedakan satu tuple dengan tuple lainnya pada R.
Key K: Superkey minimal, sedemikian hingga penghapusan salah satu attribute dari K akan menyebabkan K tidak lagi menjadi key
Jika relasi punya beberapa key, masing-masing disebut candidate key. Salah satu dari candidate key dipilih menjadi primary key.
Prime attribute: Attribute yang menjadi anggota dari candidate key
Non prime attribute: Attribute yang bukan merupakan anggota candidate key manapun.
Content Development GDLN Batch 2 31
Bentuk Normal Pertama (1NF)
Bentuk normal pertama (1NF) merupakan bagian dari definisi relasi.
Bentuk normal pertama tidak mengizinkan:– Composite attributes,– Multivalue attributes,– Nested relations.
Content Development GDLN Batch 2 32
Normalisasi ke 1NF
Content Development GDLN Batch 2 33
Normalisasi dari Nested Relation ke 1NF
Content Development GDLN Batch 2 34
Bentuk Normal Kedua (2NF) Menggunakan konsep FD dan primary key Definisi:
– Full functional dependency: suatu FD X Y sedemikian hingga jika salah satu attribute dari X dibuang, maka FD tersebut tidak ada lagi.
Contoh: – {SSN, PNUMBER} HOURS merupakan full FD,
karena tidak ada SSN HOURS dan PNUMBER HOURS
– {SSN, PNUMBER} ENAME merupakan partial dependency, bukan full FD karena terdapat dependency SSN ENAME
Content Development GDLN Batch 2 35
Bentuk Normal Kedua (2NF)
Suatu relasi R berada dalam bentuk normal kedua (2NF) jika R berada dalam 1NF dan setiap nonprime attribute A dalam relasi R bersifat full functional dependent terhadap primary key.
Suatu relasi R dapat didekomposisi ke relasi-relasi yang memenuhi 2NF melalui proses normalisasi 2NF
Content Development GDLN Batch 2 36
Contoh Normalisasi 2NF ENAME fully
dependent on SSN
PNAME, PLOCATION fully dependent on PNUMBER
Normalisasi 2NF
Content Development GDLN Batch 2 37
Contoh Normalisasi 2NF
Normalisasi 2NF
Content Development GDLN Batch 2 38
Bentuk Normal Ketiga (3NF) Suatu relasi R berada dalam bentuk normal ketiga
(3NF) jika R berada dalam 2NF dan tidak ada nonprime attribute A di R yang memiliki dependensi transitif terhadap primary key.
Suatu relasi R dapat didekomposisi ke relasi-relasi yang memenuhi 3NF melalui proses normalisasi 3NF
Catatan:– Pada FD X -> Y dan Y -> Z, dengan X sebagai primary key,
kita mempertimbangkan ini sebagai sebuah problem hanya jika Y bukan sebuah candidate key.
– Jika Y merupakan candidate key, tidak ada masalah dengan dependensi transitif ini
– Contoh: Relasi EMP (SSN, Emp#, Salary) tidak melanggar 3NF karena meskipun terdapat FD SSN Emp# Salary, Emp# merupakan candidate key
Content Development GDLN Batch 2 39
Contoh Normalisasi 3NF
Normalisasi 3NF
Content Development GDLN Batch 2 40
Contoh Normalisasi 3NF
Normalisasi 3NF
Content Development GDLN Batch 2 41
Contoh Normalisasi 3NF
Content Development GDLN Batch 2 42
Bentuk Normal Didefinisikan secara Informal
1st normal form– All attributes depend on the key
2nd normal form– All attributes depend on the whole key
3rd normal form– All attributes depend on nothing but the
key
Content Development GDLN Batch 2 43
Rangkuman Bentuk Normal Berdasarkan Primary Key
Content Development GDLN Batch 2 44
General Normal Form
Content Development GDLN Batch 2 45
Definisi dalam General Normal Form
Definisi-definisi sebelumnya hanya mempertimbangkan primary key
Definisi selanjutnya mempertimbangkan semua candidate key pada suatu relasi
Skema relasi R berada pada 2NF (general definition) jika setiap nonprime attribute A pada R bersifat full functional dependent pada setiap key pada R
Content Development GDLN Batch 2 46
Definisi dalam General Normal Form
Definisi: – Superkey pada relasi R: himpunan
attributes S dari R yang berisi key dari R– Skema relasi R berada dalam 3NF dengan
syarat jika terdapat FD X Y maka:(a) X merupakan superkey dari R atau
(b) Y merupakan prime attribute dari R
BCNF tidak membolehkan kondisi (b) di atas
Content Development GDLN Batch 2 47
Boyce Codd Normal Form
Content Development GDLN Batch 2 48
Boyce Codd Normal Form (BCNF)
Suatu skema relasi R berada pada BCNF dengan syarat jika terdapat FD X pada R, maka X merupakan superkey dari R.
Setiap BCNF pasti memenuhi 3NF Ada relasi yang berada pada 3NF
namun tidak BCNF Tujuan normalisasi umumnya untuk
mencapai 3NF atau BCNF
Content Development GDLN Batch 2 49
Contoh BCNF
Content Development GDLN Batch 2 50
Contoh: Relasi pada 3NF Namun tidak BCNF
Content Development GDLN Batch 2 51
Normalisasi BCNF Ada 2 FD pada relasi TEACH:
– fd1: { student, course} -> instructor– fd2: instructor -> course
{student, course} merupakan candidate key untuk reach – Relasi ini berada pada 3NF namun tidak
pada BCNF Relasi yang belum BCNF dapat
didekomposisi untuk mencapai BCNF, namun kadang-kadang dapat menghilangkan FD yang semula telah ada
Content Development GDLN Batch 2 52
Normalisasi BCNF Ada 3 dekomposisi yang mungkin untuk
relasi TEACH: – {student, instructor} and {student, course}– {course, instructor} and {course, student}– {instructor, course} and {instructor, student}
Semua dekomposisi tersebut kehilangan FD1– Semua FD yang ada pada relasi sedapat
mungkin dijaga, namun dapat dimaklumi jika hilang pada normalisasi BCF
– Namun sifat lossless dan non-additivity property setelah dekomposisi harus tetap dijaga
Content Development GDLN Batch 2 53
Referensi
Elmasri & Navathe, Fundamental of Database Systems, 5th Edition, Chapter 10, 2007
top related