© 2009 by Prentice Hall 1 Desain Basisdata Pengampu Matakuliah A Didimus Rumpak, M.Si. hp.: 085691055061 Didimus.

Presentasi berjudul: "© 2009 by Prentice Hall 1 Desain Basisdata Pengampu Matakuliah A Didimus Rumpak, M.Si. hp.: 085691055061 Didimus."— Transcript presentasi:

1 © 2009 by Prentice Hall 1 Desain Basisdata Pengampu Matakuliah A Didimus Rumpak, M.Si. hp.: 085691055061 dimurumpak@yahoo.com dimurumpak@yahoo.com Didimus Rumpak, M.Si. Database Concepts 1e Chapter 4 4 Dimu' Rumpak

2 © 2009 by Prentice Hall2 Bab Tujuan  Pelajari cara mengubah model data ER ke desain relasional  Memahami sifat dan latar belakang teori normalisasi  Tahu bagaimana menggunakan kriteria normalisasi untuk mengevaluasi desain relasional  Memahami perlunya denormalization Dimu' Rumpak

3 © 2009 by Prentice Hall3 Bab Tujuan (lanjutan)  Pelajari cara untuk mewakili entitas lemah dengan model relasional  Tahu bagaimana untuk mewakili 1:1, 1: N, dan N: M biner hubungan  Tahu bagaimana untuk mewakili 1:1, 1: N, dan N: M rekursif hubungan  Pelajari SQL statement untuk menciptakan bergabung lebih biner dan hubungan rekursif Dimu' Rumpak

4 © 2009 by Prentice Hall4 Representasi Entitas dengan Model Relasi  Buatlah relasi untuk setiap entitas o Sebuah relasi mempunyai nama deskriptif dan satu set atribut yang menggambarkan entitas  Relasi ini kemudian dianalisis dengan menggunakan aturan normalisasi  Sebagai isu normalisasi timbul, hubungan awal desain mungkin perlu mengubah Dimu' Rumpak

5 © 2009 by Prentice Hall5 Anomali  Hubungan yang tidak normal akan mengalami masalah yang dikenal sebagai anomali Penyisipan anomali –Kesulitan memasukkan data ke dalam hubungan Modifikasi anomali –Kesulitan memodifikasi data ke dalam hubungan Penghapusan anomali –Kesulitan menghapus data dari suatu relasi Dimu' Rumpak

6 © 2009 by Prentice Hall6 Pemecahan Anomali  Kebanyakan anomali diselesaikan dengan cara memutuskan hubungan yang sudah ada menjadi dua atau lebih relasi Dimu' Rumpak

7 © 2009 by Prentice Hall7 Normalisasi  "... Determinan dari setiap fungsional dependensi adalah kunci kandidat" Dimu' Rumpak

8 © 2009 by Prentice Hall8 Definisi  Determinan o Nilai atribut ini dapat digunakan untuk menemukan nilai atribut lain dalam hubungan  Fungsional dependensi o Hubungan (dalam hubungan) yang menggambarkan bagaimana nilai determinan dapat digunakan untuk menemukan nilai atribut lain Dimu' Rumpak

9 © 2009 by Prentice Hall9 Definisi  Candidate key o Nilai candidate key dapat digunakan untuk menemukan nilai setiap atribut lain dalam hubungan Dimu' Rumpak

10 © 2009 by Prentice Hall10 Citarasa Kunci Kandidat  Sebuah kunci kandidat komposit terdiri dari lebih dari satu atribut  Kunci kandidat yang sederhana hanya terdiri dari satu atribut Dimu' Rumpak

11 © 2009 by Prentice Hall11 Bentuk Normal  Bentuk Normal Pertama (1NF)  Bentuk Normal Kedua (2NF)  Bentuk Normal Ketiga (3NF)  Boyce-Codd Normal Form (BCNF)  Bentuk Normal Keempat (4NF)  Bentuk Normal Kelima (5NF)  Domain / Key Normal Form (DK / NF) Dimu' Rumpak

12 © 2009 by Prentice Hall12 Domain/Key Normal Form (DK/NF)  Jika  "... Determinan dari setiap fungsional dependensi adalah kundi kandidat"  Relasi ini dalam DK / NF Dimu' Rumpak

13 © 2009 by Prentice Hall13 Denormalisasi  Normalisasi hubungan (atau melanggar mereka terpisah ke dalam berbagai komponen hubungan) dapat secara signifikan meningkatkan kompleksitas struktur data  Pertanyaannya adalah salah satu keseimbangan o Trading kompleksitas untuk anomali  Ada situasi dimana hubungan denormalized lebih disukai Dimu' Rumpak

14 © 2009 by Prentice Hall14 Entitas Lemah  Untuk ID-tergantung entitas lemah, kunci induk menjadi bagian dari key dari entitas lemah Dimu' Rumpak

15 © 2009 by Prentice Hall15 Representasi Relasi  Kardinalitas maksimum menentukan bagaimana hubungan yang disimpan  Hubungan 1:1 o Kunci dari satu hubungan yang ditempatkan di lain sebagai foreign key o Tidak peduli meja yang menerima kunci asing Dimu' Rumpak

16 © 2009 by Prentice Hall16 Contoh Relasi Satu ke satu LOCKEREMPLOYEE 1:1 Dimu' Rumpak

17 © 2009 by Prentice Hall17 Representasi satu dari Satu ke satu Relasi LockerDesc Location LockerID Locker LockerID EmpName EmpID Employee Foreign Key Primary Key Dimu' Rumpak

18 © 2009 by Prentice Hall18 Representasi lain dari Satu ke satu Relasi EmpID LockerDesc Location LockerID Locker EmpName EmpID Employee Kunci Asing Kunci Utama Dimu' Rumpak

19 © 2009 by Prentice Hall19 Wajib Relasi Satu ke satu  Sebuah hubungan 1:1 wajib dapat dengan mudah runtuh kembali menjadi satu relasi. Meskipun ada saat-saat yang ditambahkan kompleksitas itu dibenarkan... o Keamanan tambahan o Komponen data yang jarang diakses ... Sangat sering hubungan ini runtuh menjadi satu Dimu' Rumpak

20 © 2009 by Prentice Hall20 Relasi Satu ke banyak  Seperti hubungan 1:1, 1: N hubungan disimpan dengan menempatkan kunci dari satu meja ke lain sebagai foreign key  Namun, dalam sebuah 1: N kunci asing selalu pergi ke banyak sisi Dimu' Rumpak

21 © 2009 by Prentice Hall21 Contoh Relasi Satu ke banyak DEPARTMENTEMPLOYEE 1:N Dimu' Rumpak

22 © 2009 by Prentice Hall22 Representasi Relasi Satu ke banyak DeptName Location DeptID Department DeptID EmpName EmpID Employee Foreign Key Primary Key Dimu' Rumpak

23 © 2009 by Prentice Hall23 Representasi Relasi Banyak ke banyak  Untuk menyimpan M: N hubungan, relasi baru dibuat. Hubungan ini disebut hubungan persimpangan  Hubungan persimpangan memiliki kunci komposit yang terdiri dari kunci dari masing-masing tabel yang membentuknya Dimu' Rumpak

24 © 2009 by Prentice Hall24 Contoh Relasi Banyak ke banyak SKILLEMPLOYEE N:M Dimu' Rumpak

25 © 2009 by Prentice Hall25 Representasi Relasi Banyak ke banyak SkillDesc SkillID Skill EmpName EmpID Employee Foreign Key EmpID SkillID Emp_Skill Foreign Key Dimu' Rumpak

26 © 2009 by Prentice Hall26 Representasi Relasi Rekursif  Sebuah hubungan rekursif adalah suatu hubungan yang memiliki sebuah relasi dengan dirinya sendiri.  Hubungan rekursif mematuhi aturan yang sama sebagai hubungan biner. o 1:1 dan 1: M hubungan akan disimpan dengan menggunakan kunci asing o M: N hubungan yang disimpan dengan menciptakan hubungan memotong Dimu' Rumpak

27 © 2009 by Prentice Hall27 Contoh Relasi Rekursif EMPLOYEE 1:N Manages Dimu' Rumpak

28 © 2009 by Prentice Hall28 Representasi Relasi Rekursif EmpID (FK) EmpName EmpID Employee Foreign Key is The EmpID of the Manager Dimu' Rumpak

29 © 2009 by Prentice Hall29 Sinonim  Sebuah sinonim dibuat ketika atribut yang sama 2 nama mengasumsikan  Sinonim sering nyaman saat menyimpan hubungan rekursif Dimu' Rumpak

30 © 2009 by Prentice Hall30 Representasi Relasi Rekursif menggunakan sinonim ManagerID EmpName EmpID Employee Kunci Asing adalah The EmpID of the Manager Dimu' Rumpak

31 © 2009 by Prentice Hall31 Perilaku Cascading  Perilaku Cascading ditentukan oleh jenis operasi o Cascade update o Cascade menghapus Dimu' Rumpak

32 © 2009 by Prentice Hall32 Perilaku Cascading –Cascading perilaku ditentukan oleh jenis operasi Cascade update Cascade menghapus Dimu' Rumpak

33 © 2009 by Prentice Hall 33 Terima Kasih Pengampu Matakuliah A Didimus Rumpak, M.Si. hp.: 085691055061 dimurumpak@yahoo.com dimurumpak@yahoo.com Didimus Rumpak, M.Si. Database Concepts 1e Chapter 4 4 Dimu' Rumpak