Sistem Basis Data

SISTEM BASIS DATA

MATERI PERKULIAHAN  Bahasan: • • • • •

Pengertian Tabel Konsep Sistem Basis Data Proses Normalisasi Proses Entity relationship (ER) Perancangan Basis Data

Albertus Deliar/2006

2

REFERENSI  Connoly, T. M. dan C. E. Begg (2002), Database Systems, A Practical Approach to Design, Implementation, and Management, 3rd Edition, Pearson Education Ltd, Edinburgh.  Howe, D. R (1982), Data Analysis for Data Base Design, Edward Arnold, Leicester.  Korth, H. F. dan A. Silberschatz (1991), Database System Concepts, Mc Graw Hill, International Editions, New York.

Albertus Deliar/2006

3

PENGERTIAN TABEL  Materi: • • • •

Pengertian dan bentuk tabel; Persyaratan sebuah tabel bentuk normal; Nilai kosong (null value) Pengertian file

Albertus Deliar/2006 - Pengertian Tabel

4

BENTUK TABEL  Terdiri atas baris dan kolom.  Perpotongan baris dan kolom memiliki nilai data/nilai attribut.  Dapat ditulis: Mahasiswa (NIM, NM_MHS, ALAMAT, KOTA) Nama tabel

Tabel Mahasiswa NIM

NM_MHS ALAMAT

KOTA

1518801

Aa

Jl. X

Bandung

1518802

Bb

Jl. Y

Jakarta

1518803

Cc

Jl. X

Surabay a

…

…

…

…

n

Cc

Jl. Z

Serang

Baris/ record

Albertus Deliar/2006 - Pengertian Tabel

Jenis (nama) kolom/item/ field/attribut

Nilai data/ attribut 5

SYARAT TABEL 1. Urutan baris boleh sembarang dan dapat dipertukarkan tanpa mempengaruhi nilai informasi tabel. 2. Urutan kolom boleh sembarang dan tiap kolom memiliki nama/jenis atribut (item name) yang berbeda (unik). 3. Perpotongan baris dan kolom berisikan hanya satu nilai atribut/data. Banyak nilai pada perpotongan baris/kolom tidak diperbolehkan. 4. Penampilan tiap baris dalam satu tabel harus berbeda, tidak boleh persis sama. Albertus Deliar/2006 - Pengertian Tabel

6

NULL VALUE  Nilai atribut bisa jadi ‘tidak ada’, karena memang tidak diketahui atau karena memang betul-betul tidak ada.

 Contoh : telur ayam tidak diketahui berapa jumlahnya meskipun hewan ini pada kenyataannya memiliki telur, sedangkan gajah betul-betul tidak memiliki telur.  Untuk setiap nilai yang ‘tidak ada’ dapat ditampilkan (meskipun tidak selalu) dengan ‘nilai’ kosong (blank). Tabel Jenis Hewan

Diskusi: Apa bedanya antara null dengan nol?

Albertus Deliar/2006 - Pengertian Tabel

HEWAN

TELUR

Angsa

2

Gajah

Ayam

0

Bebek

7

TABEL NORMAL  Tabel yang sudah memenuhi 4 syarat tabel.  Umumnya kesalahan terjadi karena tidak dipenuhinya syarat nomor 3 (tabel belum normal).  Tabel yang sudah memenuhi pengujian dari proses tertentu disebut tabel normal penuh (fully normalized table), bukan hanya tabel normal. Tabel Mahasiswa NIM

ALAMAT

1518801

Jl. X

1518802

Jl. Y, Jl. X

…

…

n

Jl. Z

Albertus Deliar/2006 - Pengertian Tabel

Tabel Mahasiswa Diskusi: Manakah yang sudah berupa tabel normal?

NIM

ALAMAT

1518801

Jl. X

1518802

Jl. Y

1518802

Jl. X

…

…

n

Jl. Z 8

KONSEP SISTEM BASIS DATA  Materi: • • • • • •

Terminologi file Pengertian basis data Kebebasan data Sistem Managemen Basis Data Arsitektur basis data Duplikasi dan redundant data

Albertus Deliar/2006 - Konsep Sistem Basis Data

9

TERMINOLOGI FILE  File atau berkas ialah sekumpulan record yang berhubungan (collection of related records).  Dalam konteks ini berupa tabel. File Nilai Mahasiswa

File Mata Kuliah

Albertus Deliar/2006 - Konsep Sistem Basis Data

10

SISTEM FILE SEDERHANA  Setiap pengguna dapat memiliki beberapa file.  Ada beberapa data yang sama dan disimpan oleh setiap pengguna di file yang berbeda.

Data nama pegawai Albertus Deliar/2006 - Konsep Sistem Basis Data

11

KRITIK SISTEM FILE  Adanya data yang berlebihan (redundant) sehingga membutuhkan tempat penyimpanan yang besar. Div. Marketing

Div. Gudang

File harga barang: Kode, nama, harga, jumlah.

File stock barang: Kode, nama, jumlah, tgl_datang Ada data yang sama namun disimpan ditempat yang berbeda oleh pengguna yang berbeda juga Albertus Deliar/2006 - Konsep Sistem Basis Data

12

KRITIK SISTEM FILE  Ketidak-konsistenan data (inconsistency). Div. Gudang

Div. Marketing

File stock barang: Kode, nama, jumlah.

File harga barang: Kode, nama, harga, jumlah.

Data awal: 001, kursi, 20

Data awal: 001, kursi, Rp. 100.000, 20

Terjadi perubahan data: 001, kursi, 40

Tidak ada perubahan data: 001, kursi, Rp. 100.000, 20

Albertus Deliar/2006 - Konsep Sistem Basis Data

13

KONSEP SISTEM BASIS DATA  Definisi basis data: • Common pool • Non-redundant • Shareable

Albertus Deliar/2006 - Konsep Sistem Basis Data

14

CONTOH BASIS DATA Tabel Nilai Mahasiswa Tabel Mt_Kuliah Kd_MK NIM Nilai

Kd_MK Nm_MK SKS

Tabel Mahasiswa

Tabel Nilai Mahasiswa

NIM Nm_Mhs Alamat

Kd_MK NIM Nilai

DBM S

Program aplikasi Bidang Akademik

Program aplikasi Bidang Akademik

Program aplikasi Bidang Keuangan

Setiap program aplikasi yang dipakai pengguna hanya dapat mengakses data yang diperlukan saja. Albertus Deliar/2006 - Konsep Sistem Basis Data

15

PANDANGAN TERHADAP DATA  Basis data memisahkan antara • pandangan program-program aplikasi (local view) dengan • pandangan terhadap data yang disimpan (global view).

 Program aplikasi dapat mengakses data tersebut melalui DBMS (data base management systems) Local view Global view

view 1

File A view 2 … view n Albertus Deliar/2006

DBMS

File B File C File D 16

DATA INDEPENDENCE  Konsep adanya pandangan program aplikasi (local view) dengan pandangan global (global view) disebut kebebasan data/program.

untuk keperluan 1 Membangun program aplikasi dengan proses hitungan, tampilan dsb

Untuk mengakses data, harus melalui DBMS

Basis Data

untuk keperluan 2

Albertus Deliar/2006 - Konsep Sistem Basis Data

17

SISTEM MANAGEMEN BASIS DATA  SMBD/DBMS ialah perangkat lunak (software) perantara untuk mengelola masukan (input), manipulasi penyimpanan dan luaran (output) dari data.  Adanya DBMS/SMBD : • Menghindari adanya redundancy dan tidak konsistensi data. • Menjamin adanya pembakuan data (standardization). • Memungkinkan adanya berbagi pakai data (data sharing). • Mencek kemanan (security) data. • Menambah, memodifikasi atau menghapus data dari basisdata, ‘menanyakan’ (queries) tentang data yang ada pada basisdata, dan juga membuat/mencetak laporan yang berisikan data yang dipilih/diinginkan. Albertus Deliar/2006 - Konsep Sistem Basis Data

18

PEMELIHARAAN DATA  Adanya kebebasan data pada DBMS memberi kemungkinan untuk mengatasi masalah ‘pemeliharaan yang tidak produktif ‘ (unproductive maintenance)  Pemeliharaan data, antara lain, mencakup: • • • •

penambahan item perubahan format item perubahan organisasi file perubahan media penyimpanan

Albertus Deliar/2006 - Konsep Sistem Basis Data

19

ARSITEKTUR DBMS  Aristektur Dua Level : • DBMS/SMBD memungkinkan adanya interface antara: − gambaran global (global view) yang menyangkut data dengan − gambaran lokal (local view) dari program-program aplikasi.

 Aristektur Tiga Level : • Gambaran global (global view ) memuat 2 informasi : − Data apa saja yang ada/tersedia pada basis data; − Cara dan bagaimana data disimpan dan diakses.

• Ditambah dengan : − Gambaran lokal (local view)

Albertus Deliar/2006 - Konsep Sistem Basis Data

20

GAMBARAN ARSITEKTUR DBMS Arsitektur 2 level

Arsitektur 3 level Model/skema Eksternal

Local View

User/view 1

User/view 2

…

User/view n

Model/skema Konseptual

Global View Model/skema Internal

Albertus Deliar/2006 - Konsep Sistem Basis Data

21

SKEMA DAN MODEL DATA  Definisi Skema (scheme): gambaran tentang data dalam suatu bahasa pemrograman yang didesain sedemikian rupa sehingga dimengerti oleh DBMS tertentu saja ≈ struktur

 Definisi Model Data: • Deskripsi data yang yang terbebas dari DBMS manapun. • Muncul karena skema yang ditulis untuk satu DBMS belum tentu berlaku untuk DBMS lainnya sehingga perlu untuk dimiliki deskripsi data yang terbebas dari DBMS manapun.

 Selanjutnya istilah model data yang akan dipakai dibandingkan skema. Albertus Deliar/2006 - Konsep Sistem Basis Data

22

DESAIN MODEL KONSEPTUAL  Dalam membangun basis data, yang penting dilakukan ialah merancang model konseptual-nya.  Perancangan model konseptual dapat dilakukan dengan cara: • Proses normalisasi – Bottom up Design • Proses entity relationship (hubungan antar entitas) – Top down design

 Hasil model konseptual ini ialah terbentuknya struktur tabel yang sudah ternormalisasi secara penuh (normal penuh/ fully normalized table).  BD = set tabel yang saling berelasi Albertus Deliar/2006 - Konsep Sistem Basis Data

23

DUPLIKASI DATA  Terjadi jika terdapat nilai data yang sama di dalam satu atau lebih kolom/item.

Albertus Deliar/2006 - Konsep Sistem Basis Data

24

REDUNDANT DATA  Data disebut berlebihan (redundant) jika dapat dihapus tanpa menghilangkan informasi atau secara pasti masih dapat diketahui/ditelusuri dari kolom lainnya (duplikasi yang tidak perlu). ?

? ? Tidak redundant Albertus Deliar/2006 - Konsep Sistem Basis Data

25

ELIMINASI REDUNDANT DATA -1  Tentukan data yang duplikat pada tabel.

Albertus Deliar/2006 - Konsep Sistem Basis Data

26

ELIMINASI REDUNDANT DATA -2  Tentukan data yang redundant pada tabel dan cara mencari informasi tersebut jika data itu dihilangkan.

Diskusi: Mengapa bukan NIM yang dianggap redundant? Albertus Deliar/2006 - Konsep Sistem Basis Data

27

ELIMINASI REDUNDANT DATA -3  Tentukan ketergantungan kolom yang berisi data redundant dengan kolom lainnya.

Kolom NM_MHS, ALAMAT_MHS dan NIP dengan NIM Kolom NM_Dosen dengan NIP Albertus Deliar/2006 - Konsep Sistem Basis Data

28

ELIMINASI REDUNDANT DATA -4  Pisahkan tabel sesuai ketergantungan kolom tersebut menjadi beberapa tabel. • Kolom NM_MHS, ALAMAT_MHS dan NIP dengan NIM • Kolom NM_Dosen dengan NIP Tabel Mahasiswa Tabel Dosen

Diskusi: Perhatikan jumlah baris/record setiap tabel yang ternyata berkurang, mengapa? Albertus Deliar/2006 - Konsep Sistem Basis Data

29

PROSES NORMALISASI  Materi: • Konsep Proses Normalisasi • Bentuk Normal 1 (Repeating Group) • Bentuk Normal 2 :    

Duplikasi data Redundant data Determinan Identifier

• Bentuk Normal 3 (Boyce-Codd) • Bentuk Normal 4 (multi-valued determinancies) • Bentuk Normal 5 (join depedencies)

Albertus Deliar/2006 - Proses Normalisasi

30

KONSEP PROSES NORMALISASI  Proses penyusunan model konseptual basis data berdasarkan hubungan antar attribut (kolom/item).  Disebut pemodelan basis data secara bottom-up.

Contoh basis data flat

Albertus Deliar/2006 - Proses Normalisasi

31

TAHAPAN PROSES NORMALISASI 1st NF: Repeating group

3rd NF: Ketergantungan transitif

2nd NF: Ketergantunga n attribut

Tabel Belum normal (unnormalised table) Tabel Bentuk Normal 1 Tabel Bentuk Normal 2 Tabel Bentuk Normal 3 Tabel Bentuk Normal 4 Tabel Bentuk Normal 5

4th NF: Determinan multiAlbertus Deliar/2006 - Proses Normalisasi valued

5th NF: Join depedency 32

TABEL BELUM NORMAL  Terjadi jika salah satu syarat tabel belum dipenuhi.  Untuk membentuk tabel normal (bukan normal penuh), maka syarat tabel harus dipenuhi.

Diskusi: Bagaimana cara mengeliminir kesalahan tabel diatas? Albertus Deliar/2006 - Proses Normalisasi

33

REPEATING GROUPS  Khusus terjadi jika syarat tabel yang menyatakan perpotongan baris dan kolom berisi satu nilai data tidak dipenuhi.

Albertus Deliar/2006 - Proses Normalisasi

34

TABEL NORMAL BENTUK 1 [1ST NF]  Cara menghilangkan kesalahan ini ialah dengan menambahkan record untuk memecah nilai data yang berisi lebih dari satu nilai.

Albertus Deliar/2006 - Proses Normalisasi

35

ENTERPRISE  Bagian dari real world yang dimodelkan oleh basis data. Pemodelan bisa jadi menyangkut seluruh organisasi (mis. perusahaan, universitas, rumah sakit, dll.), sebagian dari organisasi, atau salah satu proses atau sistem yang ada pada organisasi tsb.

 Yang perlu diketahui terlebih dahulu untuk merancang basis data adalah ‘ketentuan apa yang ada untuk mengatur segala sesuatu tentang data’.  Ketentuan apa saja (tentang data/informasi) yang ada yang (akan) diterapkan pada model untuk suatu enterprise, disebut sebagai enterprise rules. Albertus Deliar/2006 - Proses Normalisasi

36

ENTERPRISE RULES  Aturan yang diperlukan untuk mendefinisikan secara jelas dan tegas tentang transaksi, entitas dan keterkaitan antar entitas (entity relationship).  Contoh suatu enterprise rules : • Nilai yang ada untuk komp# hanya boleh memiliki satu kaitan dengan nilai des_komp. • Nilai yang ada untuk des_komp boleh memiliki kaitan dengan banyak nilai komp#. • Nilai yang ada untuk pemasok# boleh memiliki kaitan dengan banyak nilai komp#. • Nilai yang ada untuk komp# boleh memiliki kaitan dengan banyak nilai pemasok#.

Albertus Deliar/2006 - Proses Normalisasi

37

DETERMINAN -1  Berdasarkan enterprise rule, ditentukan bahwa pada suatu tabel, nilai-nilai yang duplikasi dari atribut A selalu berkaitan/berasosiasi dengan nilai item yang sama dari atribut B (melalui berbagai tampilan tabel), maka A dikatakan sebagai determinan (penentu) dari B.

• duplikasi nilai a2 pada attribut A selalu berhubungan dengan nilai yang sama dari attibut B yaitu b1. Albertus Deliar/2006 - Proses Normalisasi

38

DETERMINAN -2  Apabila nilai item a1 dan a2 (tidak duplikasi) untuk A, keduanya berasosiasi dengan nilai item yang sama atau nilai item yang berbeda (berarti berasosiasi satu-satu) dari B, maka A determinan dari B; selanjutnya dapat dikatakan bahwa A ‘menentukan’ B, dan B ‘ditentukan’ oleh (atau tegantung pada ) A.  Lebih tegas lagi apabila duplikasi tidak boleh muncul pada atribut A, maka A (dapat dipastikan) determinan dari B

Albertus Deliar/2006 - Proses Normalisasi

39

CONTOH DETERMINAN  Tentukan attribut yang menjadi determinan?

 komp# determinan dari des_komp  komp# determinan dari juml_stok

 des_komp bukan determinan dari komp#, mengapa?  bagaimana juml_stok terhadap komp#?

Albertus Deliar/2006 - Proses Normalisasi

40

DETERMINAN KOMPOSIT  Manakah attribut yang menjadi determinan?

 Attribut gabungan {toko#, barang} merupakan determinan komposit dari attribut juml_stok Albertus Deliar/2006 - Proses Normalisasi

41

ATTRIBUTE SUPERFLUOUS  Dikatakan berlebihan jika ternyata suatu determinan tidak akan berisikan atribut yang ‘berlebihan’.

 Dapatkah attribut komposit {komp#, desk_komp} menjadi determinan terhadap attribut juml_stok?  Baikkah determinan tersebut? Albertus Deliar/2006 - Proses Normalisasi

42

DIAGRAM DETERMINAN  Diagram determinansi membantu dalam melihat adanya determinan dan atribut-atribut yang dideterminansi. A A

B

Attribut A determinan dari attribut B

B

Attribut A determinan dari attribut B dan attribut B determinan dari attribut A

 Diagram determinansi dapat digunakan untuk menyatakan dengan lebih baik tentang ketentuan yang ada pada enterprise rule. Albertus Deliar/2006 - Proses Normalisasi

43

CONTOH DIAGRAM DETERMINAN -1 des_komp

komp# juml_stok

 setiap satu nilai item yang ada pada komp# hanya berasosiasi dengan satu nilai item pada des_komp dan satu nilai item pada juml_stok.

Albertus Deliar/2006 - Proses Normalisasi

44

CONTOH DIAGRAM DETERMINAN -2



Enterprise rule : 1. Seorang pemasok diidentifikasi dengan satu nilai pemas#, dan satu komponen diidentifikasi oleh satu nilai komp#; 2. Setiap pemasok hanya memiliki satu nama, tetapi diantara para pemasok mungkin memiliki nama yang sama; 3. Seorang pemasok dapat memasok banyak jenis komponen dalam bentuk/ukuran kemasan yang berbeda; 4. Satu jenis komponen dapat dipasok oleh lebih dari satu pemasok dalam bentuk/ukuran kemasan yang berbeda; 5. Satu pemasok yang ditentukan memasok satu komponen yang ditentukan hanya dalam satu bentuk/ukuran kemasan.

Albertus Deliar/2006 - Proses Normalisasi

45

PROSES DIAGRAM DETERMINAN 1. Penggambaran kotak untuk setiap atribut yang ada. pemas#

nama_pemas

komp#

kemasan

2. Penggambaran diagram determinansinya pemas#

nama_pemas

komp#

kemasan

Albertus Deliar/2006 - Proses Normalisasi

46

IDENTIFIER (ID) BARIS/TABEL  Ketentuan bahwa dua baris pada suatu tabel tidak boleh (memiliki nilai) yang identik (sama persis) dapat diartikan bahwa setiap baris selalu dapat diidentifikasi/ditelusuri ‘melalui’ nilai item dari suatu atribut yang ada pada baris tersebut.

 Attribut yang nilai datanya dapat mengidentifikasi atau menelusuri secara tepat ‘satu’ baris disebut sebagai ‘IDENTIFIER’ (pengenal).  Identifier berfungsi sebagai ‘label/tanda’ untuk suatu baris = harus diketahui nilainya = tidak boleh memiliki nilai ‘tidak ada/diketahui’ (null value). Albertus Deliar/2006 - Proses Normalisasi

47

DETERMINAN DAN IDENTIFIER  Untuk mengenali suatu identifier dengan mudah dapat dicari dari diagram determinan. des_komp komp# juml_stok

Identifier

 Mengapa determinan dapat menjadi ID?

Albertus Deliar/2006 - Proses Normalisasi

48

CONTOH IDENTIFIER -1  Tabel: • toko (toko#, barang, juml_stok)

 Manakah ID tabel/baris-nya? barang toko# juml_stok Albertus Deliar/2006 - Proses Normalisasi

49

CONTOH IDENTIFIER -2

 Dapatkah (komp#, des_komp) menjadi ID komposit dari baris atau tabel diatas?  ID superfluous tidak diperkenankan

Albertus Deliar/2006 - Proses Normalisasi

50

DIAG. DETERMINAN & REDUNDANT -1  Jika suatu enterprise rules dapat direpresentasikan atau disajikan oleh suatu diagram determinansi, maka akan dengan mudah dapat dilakukan pencarian dan pengeliminasian data redundant pada suatu struktur tabel.

 Misalkan ada tabel seperti berikut : Pelanggan-Penjaja (pelanggan#, penjaja#, nama penjaja)

 E-Rules: • Setiap pelanggan# berasosiasi dengan satu penjaja#; • Setiap penjaja# (dapat) berasosiasi dengan beberapa/ sejumlah pelanggan#.

Albertus Deliar/2006 - Proses Normalisasi

51

DIAG. DETERMINAN & REDUNDANT -2 pelanggan# Determinan identifier

penjaja# Determinan

nama_penjaja

• penjaja# akan memiliki nilai duplikasi, jika tidak berarti penjaja# akan jadi identifier dan konsekuensinya merupakan satu determinan untuk pelanggan#; • penjaja# determinan nama_penjaja. Setiap pemunculan duplikasi dari penjaja# akan berasosiasi dengan nilai nama_penjaja; nama_penjaja akan memiliki nilai redundant; • Dilain pihak nilai pelanggan# tidak mungkin duplikasi karena pelanggan# merupakan suatu identifier , oleh karenanya tidak akan ada nilai redundant untuk penjaja#; • Potensi terjadinya nilai redundant akan muncul disebabkan penjaja# merupakan suatu determinan tapi belum merupakan ‘calon/kandidat identifier’. Albertus Deliar/2006 - Proses Normalisasi

52

DIAG. DETERMINAN & REDUNDANT -2 pelanggan# Determinan identifier pelanggan#

PL01 PL07 PL10 PL20 PL22 • • • •

penjaja# Determinan

nama_penjaja

penjaja# nama_penjaja PJ11 PJ05 PJ12 PJ11 PJ19

Siti Ani Rara Siti Siti

penjaja# akan memiliki nilai duplikasi, jika tidak berarti penjaja# akan jadi identifier dan konsekuensinya merupakan satu determinan untuk pelanggan#; penjaja# determinan nama_penjaja. Setiap pemunculan duplikasi dari penjaja# akan berasosiasi dengan nilai nama_penjaja; nama_penjaja akan memiliki nilai redundant; Dilain pihak nilai pelanggan# tidak mungkin duplikasi karena pelanggan# merupakan suatu identifier , oleh karenanya tidak akan ada nilai redundant untuk penjaja#; Potensi terjadinya nilai redundant akan muncul disebabkan penjaja# merupakan suatu determinan tapi belum merupakan ‘calon/kandidat identifier’.

Albertus Deliar/2006 - Proses Normalisasi

53

PROSES BENTUK NORMAL 2 -1  Menyusun ketergantungan setiap attribut terhadap attribut kuncinya (ID).  Perlu penggambaran diagram determinan untuk mengetahui ID baris.

Albertus Deliar/2006 - Proses Normalisasi

54

PROSES BENTUK NORMAL 2 -2 Determinan Identifier

pemas#

nama_pemas

komp#

kemasan

pemas#

pemas#

nama_pemas

Determinan Identifier

Albertus Deliar/2006 - Proses Normalisasi

komp#

kemasan

Determinan Identifier

55

TABEL NORMAL BENTUK 2 [2ND NF] Tabel Pemasok

Tabel normal bentuk 2 yang terbentuk ialah: Pemasok(pemas#, nama_pemas) Komponen(pemas#, komp#, kemasan) *Simbol __ berarti ID

Tabel Komponen

Albertus Deliar/2006 - Proses Normalisasi

56

DETERMINAN TRANSITIF  Jika atribut A determinan dari atribut B, dan atribut B determinan dari atribut C, maka atribut A harus merupakan determinan dari atribut C.  Atribut A dikatakan sebagai determinan transitif dari atribut C; sebaliknya atribut C dikatakan memiliki ketergantungan transitif (transitively dependent ) terhadap A.

Albertus Deliar/2006 - Proses Normalisasi

57

ATURAN BOYCE-CODD Setiap determinan harus menjadi kandidat identifier  Aturan ini dipakai untuk mendeteksi adanya redundancy pada suatu tabel  Tabel yang memenuhi aturan ini disebut sebagai tabel dengan Bentuk Normal Boyce/Codd - BNBC (Boyce/ Codd Normal Form - BCNF) atau ‘normal yang betul’ (well normalised table)

 Bentuk ini merupakan Tabel Normal Bentuk 3

Albertus Deliar/2006 - Proses Normalisasi

58

PROSES BENTUK NORMAL 3

pelanggan#

penjaja#

determinan dan identifier

nama_penjaja

determinan

 ada suatu tabel yang memiliki determinan yang bukan identifier (terjadi redundancy).  Mengubah tabel yang demikian menjadi BNBC dengan cara membentuk tabel baru sedemikian rupa sehingga determinan non-identifier pada tabel lama menjadi identifier. Albertus Deliar/2006 - Proses Normalisasi

59

TABEL NORMAL BENTUK 3 [3rd NF] / BNBC pelanggan#

penjaja#

determinan dan identifier

penjaja#

nama_penjaja

determinan dan identifier

Albertus Deliar/2006 - Proses Normalisasi

60

TABEL NORMAL PENUH  Dipakai untuk mendeskripsikan sekumpulan tabel yang terstruktur sehingga tidak berisi data redundant.  Dalam banyak kasus, tabel normal baik sudah merupakan tabel normal penuh.

 Dalam beberapa kasus, perlu dilakukan proses lebih lanjut.

Albertus Deliar/2006 - Proses Normalisasi

61

HIDDEN TRANSITIVE DEPENDENCY -1 Manakah yang benar? Pesanan (pesanan#, pelanggan#, nama_pel) (a)

pesanan#

pelanggan#

(b) Versi A Pes-Pel (pesanan#, pelanggan#) Pelanggan-1 (pelanggan#, nama_pel)

Albertus Deliar/2006 - Proses Normalisasi

nama_pel

Versi B Pes-Pel (pesanan#, pelanggan#) Pelanggan-2 (pesanan#, nama_pel)

62

HIDDEN TRANSITIVE DEPENDENCY -2 (c)

Pes-Pel

Pelanggan1

Pelanggan2

 Bagaimana jika nama pelanggan P1 berubah dari Suma menjadi Sumo?

Albertus Deliar/2006 - Proses Normalisasi

63

Normalkan tabel berikut ini !

Albertus Deliar/2006

64

QUIZ Pengarang(autor#, nama_autor, buku#, judul_buk, nama_suby).        

Autor# : kode penulis Nama_autor : nama penulis Buku# : kode buku Judul_buk : judul buku Nama_suby : jenis buku (biologi, fisika dsb) Setiap penulis dapat menulis banyak buku Setiap buku dapat ditulis banyak penulis Setiap buku dapat memiliki beberapa subyek

 Buatlah tabel normal penuhnya.  Berikan contoh tabel pemunculannya. Albertus Deliar/2006 - Proses Normalisasi

65

PROSES ENTITY RELATIONSHIP (ER)  Materi: • • • • • • • •

Konsep Proses Entity Relationship Properti relasi Dekomposisi hubungan banyak ke banyak Perangkap relasi Model skeleton entity relationship Pemasangan attribut Desain tingkat pertama Desain tingkat dua

Albertus Deliar/2006 - Proses Entity Relationship

66

KONSEP ENTITY RELATIONSHIP Entitas 1 Entitas 2

Entitas 3

Entitas …

Entitas n

Proses Entity Relationship

Pemasangan Attribut Tabel Normal Penuh

Tabel 1

Tabel 2

Tabel …

Tabel n

Proses Normalisasi Attribut 1 Attribut 2 Attribut 3

Albertus Deliar/2006 - Proses Entity Relationship

Attribut … Attribut n

67

MODEL ENTITY RELATIONSHIP  Entity/ Entitas

: a thing (object, concept)

 Attribut

: a property of an entity

 Relationship

: an association between two (or more) entities

Entitas kendaraan darat !!!

Albertus Deliar/2006 - Proses Entity Relationship

Propertinya ???

68

ENTITAS  Setiap entitas memiliki anggota entitas.  Entitas dapat direpresentasikan sebagai tabel dengan: • Nama entitas = nama tabel • Karakteristik entitas = attribut tabel (kolom) • Anggota entitas = baris/record

 Untuk membedakan anggota entitas diperlukan suatu ‘kode’ yang disebut sebagai ID Entitas. • Entitas Mahasiswa memiliki ID Entitas NIM • Entitas Dosen memiliki ID Entitas NIP

Albertus Deliar/2006 - Proses Entity Relationship

69

CONTOH MODEL ER Entitas komputer & Propertinya??

Entitas harddisk & Propertinya??

Hubungan keduanya ?? Albertus Deliar/2006 - Proses Entity Relationship

70

JENIS ENTITAS & PEMUNCULANNYA  Entitas

: Gudang, Produk

 Relasi

: menyimpan

 Attribut

: G1 Jakarta, G2 Bandung, P2 Printer, …

GUDANG G1 Jakarta G2 Bandung

SIMPAN

BARANG B4 Printer B2 Scanner B5 Plotter B3 Harddisk

Albertus Deliar/2006 - Proses Entity Relationship

71

DIAGRAM ENTITY RELATIONSHIP (ER)  Menggambarkan hubungan semua entitas.  Dalam diagram, dituliskan juga derajat dan kelas keanggotaan (dibahas kemudian)

GUDANG

SIMPAN

BARANG

Relasi

Albertus Deliar/2006 - Proses Entity Relationship

72

DERAJAT HUBUNGAN/RELASI  Menunjukkan hubungan antar anggota dari suatu entitas terhadap anggota dari entitas lainnya.  Derajat hubungan ditentukan dari enterprise rules.  Secara mudah dapat diketahui melalui diagram pemunculannya. Dalam menggambarkan diagram pemunculannya, anggota entitas cukup diwakili oleh ID entitas saja. GUDANG G1 G2

SIMPAN

BARANG B4 B2 B3

Albertus Deliar/2006 - Proses Entity Relationship

73

DERAJAT 1:1  Enterprise Rules : • Seorang dosen (hampir selalu) mengajar satu matakuliah. • Satu mata-kuliah (hampir selalu) diajar oleh satu dosen. DOSEN 130 000 001 130 000 002 130 000 003 130 000 004

AJAR

KULIAH GD3132 GD4444 GD4491 GD1111

Diskusi: Bagaimana bentuk diagram pemunculan untuk E-Rules: • Seorang dosen secara pasti mengajar satu mata-kuliah. • Satu mata-kuliah secara pasti diajar oleh satu dosen. Albertus Deliar/2006 - Proses Entity Relationship

74

DERAJAT 1:BANYAK / BANYAK:1  Enterprise Rules : • Seorang dosen kemungkinan mengajar banyak matakuliah. • Satu mata-kuliah (hampir selalu) diajar oleh satu dosen. DOSEN 130 000 001 130 000 002 130 000 003 130 000 004

AJAR

KULIAH GD3132 GD4444 GD4491 GD1111 GD1112

Diskusi: Bagaimana bentuk diagram pemunculan untuk E-Rules: • Seorang dosen diharuskan mengajar lebih dari satu mata-kuliah. • Satu mata-kuliah secara pasti diajar oleh satu dosen. Albertus Deliar/2006 - Proses Entity Relationship

75

DERAJAT BANYAK:BANYAK  Enterprise Rules : • Seorang dosen kemungkinan mengajar banyak matakuliah. • Satu mata-kuliah kemungkinan diajar oleh banyak dosen. DOSEN 130 000 001 130 000 002 130 000 003 130 000 004

Albertus Deliar/2006 - Proses Entity Relationship

AJAR

KULIAH GD3132 GD4444 GD4491 GD1111 GD1112

76

DIAGRAM ER & DERAJAT RELASI  Derajat relasi digambarkan dalam diagram ER. DOSEN

DOSEN

DOSEN

1

1

m

Albertus Deliar/2006 - Proses Entity Relationship

AJAR

AJAR

AJAR

1

n

n

KULIAH

1:1

KULIAH

1:n

KULIAH

m:n

77

KELAS KEANGGOTAAN  Menunjukkan apakah semua anggota entitas memiliki hubungan dengan anggota entitas lagi secara pasti atau tidak.  Kelas keanggotaan: • OBLIGATORY / OBL (wajib): Jika semua anggota entitas secara pasti berhubungan dengan anggota entitas lainnya.

• NON-OBLIGATORY / NON_OBL : Jika tidak semua anggota entitas secara pasti berhubungan dengan anggota entitas lainnya.

Albertus Deliar/2006 - Proses Entity Relationship

78

CONTOH OBL/OBL  Enterprise rules: • Satu Departemen harus mempekerjakan paling tidak satu Karyawan. • Seorang Karyawan harus dipekerjakan paling tidak oleh satu Departemen. Departemen

kerja

Karyawan

 Anggota kedua entitas tersebut secara pasti berhubungan sehingga keduanya memiliki kelas obligatory Albertus Deliar/2006 - Proses Entity Relationship

79

CONTOH NON_OBL-NON_OBL  Enterprise rules: • Satu Departemen tidak perlu mempekerjakan seorang Karyawan-pun. • Seorang Karyawan tidak perlu dipekerjakan oleh Departemen manapun. Departemen

kerja

Karyawan

 Anggota kedua entitas tersebut tidak selalu memiliki hubungan satu sama lain sehingga keduanya memiliki kelas non-obligatory Albertus Deliar/2006 - Proses Entity Relationship

80

CONTOH OBL-NON_OBL  Enterprise rules: • Satu Departemen tidak perlu mempekerjakan seorang Karyawan-pun. • Seorang Karyawan harus dipekerjakan paling tidak oleh satu Departemen. Departemen

kerja

Karyawan

 Anggota entitas Departemen tidak selalu memiliki hubungan dengan anggota entitas Karyawan sehingga memiliki kelas non-obligatory.  Sebaliknya untuk entitas Karyawan sehingga berkelas obligatory Albertus Deliar/2006 - Proses Entity Relationship

81

TABEL SKELETON (KERANGKA) ER  Diagram E-R digunakan untuk menggambarkan berbagai unsur penting dari model konseptual, tetapi tidak menunjukkan atribut-attribut yang berhubungan dengan entitas dan jenis hubungannya (relationship).

 Informasi tambahan tersebut, tentang keterkaitan attribut-attribut, dapat direpresentasikan dalam bentuk tabel normal penuh.  Representasi jenis tabel untuk setiap entitas dan jenis relasinya yang berupa tabel normal penuh (belum berisi attribut lainnya) disebut tabel skeleton ER. Albertus Deliar/2006 - Proses Entity Relationship

82

REPRESENTASI HUBUNGAN 1:1  Ada ketentuan tentang dosen dan mata kuliah: • Seorang dosen maksimal dapat mengajar satu matakuliah. • Satu mata-kuliah maksimal dapat diajar oleh satu dosen.

 Setiap dosen dapat diidentifikasi melalui NIP.

 Setiap mata kuliah dapat diidentifikasi dengan Kode_MK  Kondisi ini menggambarkan derajat relasi 1:1.

 Representasi entitas dalam bentuk tabel: • Entitas Dosen (NIP, …) • Entitas Kuliah (Kode_MK, …) Albertus Deliar/2006 - Proses Entity Relationship

83

DERAJAT 1:1 / KELAS OBL-OBL  Enterprise rules: • Seorang dosen selalu mengajar satu mata-kuliah. • Satu mata-kuliah selalu diajar oleh satu dosen.

AJAR

DOSEN

KULIAH

130 000 001 130 000 002

GD3333 GD4444 GD2222 GD1111

130 000 003 130 000 004

DOSEN

Albertus Deliar/2006 - Proses Entity Relationship

1

AJAR

1

KULIAH

84

TABEL SKELETON 1:1/OBL-OBL  Karena keduanya obligatory maka kedua entitas tersebut dapat digabungkan membentuk 1 tabel normal penuh. Dengan kata lain, attribut entitas Dosen dapat dipasangkan (posted) ke dalam attribut entitas Kuliah, atau sebaliknya.

 Terbentuk 1 tabel: • Tabel Dosen_Kuliah (NIP, …, Kode_MK, …)

Albertus Deliar/2006 - Proses Entity Relationship

85

DERAJAT 1:1 / KELAS OBL-NON_OBL  Enterprise rules: • Seorang dosen dapat mengajar satu mata-kuliah atau tidak. • Satu mata-kuliah selalu diajar oleh satu dosen. AJAR

DOSEN

KULIAH

130 000 001 130 000 002

GD3333 GD4444 GD2222 GD1111

130 000 003 130 000 004 130 000 005

DOSEN

Albertus Deliar/2006 - Proses Entity Relationship

1

AJAR

1

KULIAH

86

TABEL SKELETON 1:1/OBL-NON_OBL  ID entitas non-obligatory harus dipasangkan ke entitas Artinya, ID entitas Dosen dipasangkan (posted) ke dalam entitas Kuliah.  Terbentuk 2 tabel: • Tabel Dosen (NIP, …) • Tabel Kuliah (Kode_MK, …, NIP)

Albertus Deliar/2006 - Proses Entity Relationship

87

DERAJAT 1:1 / KELAS NON_OBL-NON_OBL  Enterprise rules: • Seorang dosen dapat mengajar satu mata-kuliah atau tidak. • Satu mata-kuliah tidak selalu diajar oleh dosen. AJAR

DOSEN

KULIAH

130 000 001 130 000 002

GD3333 GD4444 GD2222 GD1111 GD5555

130 000 003 130 000 004 130 000 005

DOSEN

Albertus Deliar/2006 - Proses Entity Relationship

1

AJAR

1

KULIAH

88

TABEL SKELETON 1:1/NON_OBL-NON_OBL  ID entitas non-obligatory harus membentuk satu tabel penghubung. Artinya, ID entitas Dosen dan ID entitas Kuliah dipasangkan (posted) ke tabel baru.  Terbentuk 3 tabel: • Tabel Dosen (NIP, …) • Tabel Dosen_Kuliah (NIP, Kode_MK) • Tabel Kuliah (Kode_MK, …)

Albertus Deliar/2006 - Proses Entity Relationship

89

REPRESENTASI HUBUNGAN 1:n  Ada ketentuan tentang dosen dan mata kuliah: • Seorang dosen dapat mengajar lebih dari satu matakuliah. • Satu mata-kuliah maksimal dapat diajar oleh satu dosen.

 Setiap dosen dapat diidentifikasi melalui NIP.

 Setiap mata kuliah dapat diidentifikasi dengan Kode_MK  Kondisi Dosen:Kuliah menggambarkan derajat relasi 1:n.  Representasi entitas dalam bentuk tabel: • Entitas Dosen (NIP, …) • Entitas Kuliah (Kode_MK, …) Albertus Deliar/2006 - Proses Entity Relationship

90

DERAJAT 1:n / KELAS OBL-OBL  Enterprise rules: • Seorang dosen selalu mengajar satu atau lebih matakuliah. • Satu mata-kuliah selalu diajar oleh satu dosen.

AJAR

DOSEN

KULIAH

130 000 001 130 000 002

GD3333 GD4444 GD2222 GD1111

130 000 003

DOSEN

Albertus Deliar/2006 - Proses Entity Relationship

1

AJAR

n

KULIAH

91

TABEL SKELETON 1:n/OBL-OBL  Keduanya obligatory namun berelasi 1:n maka ID entitas [1] dipasangkan ke entitas [n]. Artinya NIP dipasangkan (posted) ke entitas Kuliah  Terbentuk 2 tabel: • Tabel Dosen (NIP, …) • Tabel Kuliah (Kode_MK, …, NIP)

Albertus Deliar/2006 - Proses Entity Relationship

92

DERAJAT 1:n / KELAS OBL-NON_OBL  Enterprise rules: • Seorang dosen selalu mengajar satu atau lebih matakuliah. • Satu mata-kuliah dapat atau tidak diajar oleh satu dosen.

AJAR

DOSEN

KULIAH

130 000 001 130 000 002

GD3333 GD4444 GD2222 GD1111 GD5555

130 000 003

DOSEN

Albertus Deliar/2006 - Proses Entity Relationship

1

AJAR

n

KULIAH

93

TABEL SKELETON 1:n/OBL-NON_OBL  Karena derajat hubungannya 1:n dan tabel ‘banyak’ (many) berkelas non-obligatory maka perlu dibentuk tabel penghubung.  Terbentuk 3 tabel: • Tabel Dosen (NIP, …) • Tabel Dosen-Kuliah (NIP, Kode_MK) • Tabel Kuliah (Kode_MK, …)

Albertus Deliar/2006 - Proses Entity Relationship

94

DERAJAT 1:n / KELAS NON_OBL-OBL  Enterprise rules: • Seorang dosen dapat mengajar satu atau lebih matakuliah atau tidak • Satu mata-kuliah selalu diajar oleh dosen.

AJAR

DOSEN

KULIAH

130 000 001 130 000 002

GD3333 GD4444 GD2222 GD1111

130 000 003 130 000 004

DOSEN

Albertus Deliar/2006 - Proses Entity Relationship

1

AJAR

n

KULIAH

95

TABEL SKELETON 1:n/NON_OBL-OBL  karena derajat hubungannya 1:n dan tabel ‘1’ (one) berkelas non-obligatory maka ID tabel ‘1’ dipasangkan ke tabel ‘banyak’.  Terbentuk 2 tabel: • Tabel Dosen (NIP, …) • Tabel Kuliah (Kode_MK, …, NIP)

Albertus Deliar/2006 - Proses Entity Relationship

96

DERAJAT 1:n / KELAS NON-NON  Enterprise rules: • Seorang dosen dapat mengajar satu atau lebih matakuliah. • Satu mata-kuliah dapat diajar oleh satu atau lebih dosen.

AJAR

DOSEN

KULIAH

130 000 001 130 000 002

GD3333 GD4444 GD2222 GD1111 GD5555

130 000 003 130 000 004

DOSEN

Albertus Deliar/2006 - Proses Entity Relationship

1

AJAR

n

KULIAH

97

TABEL SKELETON 1:n/NON-NON  Karena jeduanya berkelas non-obligatory maka perlu dibentuk tabel penghubung.  Terbentuk 3 tabel: • Tabel Dosen (NIP, …) • Tabel Dosen-Kuliah (NIP, Kode_MK) • Tabel Kuliah (Kode_MK, …)

Albertus Deliar/2006 - Proses Entity Relationship

98

REPRESENTASI HUBUNGAN m:n  Untuk jenis hubungan ‘many to many’ ini tidak perlu memperhatikan kelas keanggotaan.  Untuk menghubungkan dua entitas selalu diperoleh tiga tabel, dimana satu tabel merupakan tabel penghubung yang berisikan attribut identifier dari kedua tabel lainnya.  Jika ada ketentuan tentang dosen dan mata kuliah: • Seorang dosen dapat mengajar lebih dari satu matakuliah. • Satu mata-kuliah dapat diajar oleh lebih satu dosen. • Setiap dosen dapat diidentifikasi melalui NIP. • Setiap mata kuliah dapat diidentifikasi dengan Kode_MK Albertus Deliar/2006 - Proses Entity Relationship

99

DERAJAT m:n  Enterprise rules: • Seorang dosen dapat mengajar satu atau lebih matakuliah. • Satu mata-kuliah dapat diajar oleh satu atau lebih dosen. DOSEN

AJAR

KULIAH

130 000 001 130 000 002

GD3333 GD4444 GD2222 GD1111 GD5555

130 000 003 130 000 004

DOSEN

m

Albertus Deliar/2006 - Proses Entity Relationship

AJAR

n

KULIAH

100

TABEL SKELETON m:n  Karena jeduanya berderajat banyak-banyak maka perlu dibentuk tabel penghubung.  Terbentuk 3 tabel: • Tabel Dosen (NIP, …) • Tabel Dosen-Kuliah (NIP, Kode_MK) • Tabel Kuliah (Kode_MK, …)

Albertus Deliar/2006 - Proses Entity Relationship

101

TUGAS  Buatlah review tentang proses pembentukan tabel skeleton ER untuk semua kombinasi derajat dan kelas.  Berikan juga alasan mengapa tabel yang terbentuk harus demikian. Contoh, pada derajat 1:1 dan kelas non_obl-non_obl harus terbentu 3 tabel, mengapa tidak 2 tabel? Berikan alasan dan juga ilustrasinya.  Review ini tidak boleh sama dengan bahan transparansi yang ada, baik tulisan maupun contoh, dan harus berupa narasi.

Albertus Deliar/2006 - Proses Entity Relationship

102

DEKOMPOSISI BANYAK-BANYAK  Merupakan pemisahan relasi m:n menjadi dua relasi 1:n.  Hal ini dikarenakan adanya beberapa SMBD yang tidak mampu menangani relasi m:n.

 Jika dilakukan proses entity relationship, maka dekomposisi tersebut secara pasti dilakukan, karena hubungan m:n akan membentuk 3 tabel. DOSEN

DOSEN

1

Albertus Deliar/2006 - Proses Entity Relationship

m

AJAR n

n

Dosen_Kuliah

n

KULIAH 1

KULIAH 103

PERANGKAP RELASI  Merupakan perangkap yang adakalanya dijumpai oleh perancang & pemakai model konseptual yang harus dihilangkan.  Perangkap ini biasanya muncul akibat salah interpretasi dalam mengartikan relasi (relationship).

Dari gambar diatas, apakah interpretasi yang dapat diberikan (pilih) : 1. Penjaga mengawasi hewan; 2. Makanan adalah yang dimakan hewan; 3. Makanan yang diawasi oleh penjaga; 4. Makanan adalah yang dimakan penjaga; 5. Hewan menyukai makanan; 6. Hewan diberi makan penjaga. Albertus Deliar/2006 - Proses Entity Relationship

104

PERANGKAP KIPAS (FAN TRAP)  Sering muncul pada bentuk relasi n:1-1:n.  Sebagai contoh : • Dari gambar (a) dibentuk hubungan Departemen ke Pekerja melalui Divisi yang sangat mungkin dalam menyimpulkan pekerja mana dimiliki oleh departemen mana. 1

n Departeme n

Divisi

Termasuk dept

1 Termasuk pek

n

(a)

Pekerja

Diskusi: Apa enterprise yang dapat diambil dari diagram diatas? Albertus Deliar/2006 - Proses Entity Relationship

105

HASIL INTERPRETASI • Dari gambar b memperlihatkan kesimpulan tersebut tidak dapat terjadi karena tidak ada cara untuk mengetahui pekerja 1, 2, 3 dimiliki oleh departemen 1 atau 2. • Hal yang mungkin terpikirkan ialah pekerja dimiliki oleh divisi tetapi bukan departemen. DEPARTEMEN

Termasuk dept

DIVISI

1

P2 P3

C D

PEKERJA P1

A B

Termasuk pek

2

(b)

P4

P5 Diskusi: Bagaimana diagram yang seharusnya dari hasil interpretasi? Albertus Deliar/2006 - Proses Entity Relationship

106

INTERPRETASI DAN DIAGRAM  Struktur ini mengeliminir ketidakjelasan tentang pekerja mana dimiliki departemen mana sehingga tidak ada keraguan untuk mengetahui pekerja mana milik divisi mana Departeme n 1 1

n

Termasuk dept

Divisi

Termasuk pek

(c)

n Pekerja

 Pemahaman tentang enterprise yang ada harus benar-benar dimengerti agar tidak salah dalam menginterpretasikannya ke bentuk struktur relasi. Albertus Deliar/2006 - Proses Entity Relationship

107

DEFINISI  tabel skeleton ialah suatu jenis tabel dimana berisikan hanya identifier (entitas atau penghubungnya)–nya bersama-sama dengan identifier yang dipasangkan (posted).  model E-R (skeleton) ialah kombinasi dari diagram E-R dan tabel skeleton.  jenis tabel entitas atau jenis tabel relationship ialah berupa suatu tabel.

Albertus Deliar/2006 - Proses Entity Relationship

108

QUIZ (30’)  Pasien, yang diidentifikasikan dengan pasien#, memiliki jadwal pertemuan konsultasi dengan dokter, yang diidentifikasikan dengan no_dokter. Rekaman pertemuan setiap harinya antar pasien dan dokter akan disimpan. Setiap pasien dapat saja bertemu lebih dari satu kali dengan dokter yang sama dalam beberapa hari.  Buatlah model kerangka ER secara lengkap.  Attribut yang diperlukan dapat ditambahkan sesuai kebutuhan.

Albertus Deliar/2006 - Proses Entity Relationship

109

PERANCANGAN BASIS DATA  Materi: • Desain Tingkat 1 (1st level design)

Albertus Deliar/2006 - Proses Entity Relationship

110

1ST LEVEL DESIGN  Digunakan karena rancangan akan dibutuhkan untuk pekerjaan selanjutnya dalam mentransformasikan desain ke implementasi akhir.  Mencakup : • Analisis data, yaitu kepemilikan data yang dibutuhkan untuk analisis. • Analisis fungsional, yaitu bentuk transaksi yang akan dioperasikan.

Albertus Deliar/2006 - Perancangan Basis Data

111

CONTOH SKENARIO PERPUSTAKAAN Suatu perpustakaan menyimpan data peminjam buku. Setiap peminjam buku diidentifikasikan dengan PEMINJAM# dan setiap buku oleh BUKU# (setiap judul buku memiliki persediaan lebih dari satu buku). Nama dan alamat dari setiap peminjam ditangani juga untuk memudahkan komunikasi seperti mengingatkan batas waktu peminjaman. Informasi yang diperlukan untuk buku-buku itu ialah judul, pengarang, penerbit, tgl. terbit, ISBN (International Standard Book Number), harga beli dan harga aktual (saat ini). Terdapat suatu batasan jumlah buku yang dapat diperoleh setiap kali pinjam, batas itu tergantung klasifikasi status peminjam yaitu sebagai junior atau senior. Buku-buku yang keluar dapat dipesan bagi peminjam lainnya tergantung waktu pengembalian. Perpustakaan menyediakan buku-buku versi terakhir saja. Jika versi terbaru muncul maka versi yang lama akan disingkirkan. Albertus Deliar/2006 - Perancangan Basis Data

112

LANGKAH 1 Sketsalah permasalahan dengan diagram E-R secara bebas. • Diagram ini digambarkan secara sederhana untuk membantu pemikiran awal tentang data yang dibutuhkan, atau • Gambarkan secara singkat (sketsa) permasalahan.

Albertus Deliar/2006 - Perancangan Basis Data

113

LANGKAH 2 Persiapkan suatu daftar awal transaksi dimana model data harus dapat mendukungnya. • Menyusun suatu daftar transaksi (tujuan setiap transaksi dinyatakan, daripada menuliskan proses attribut secara detail) : a.Menyimpan detail dari peminjam baru. b.Menyimpan detail dari pembelian baru. c. Membuat peminjaman. d.Merekam pengembalian peminjaman. e.Menghapus peminjam. f. Menghapus pembelian. g.Memesan buku. h.Menghapus pemesanan. i. Memperbaharui harga saat ini (harga aktual). j. Mengirimkan pesan yang lewat batas waktu peminjaman. Albertus Deliar/2006 - Perancangan Basis Data

114

LANGKAH 3 Persiapkan suatu daftar awal atribut. • Menyusun suatu daftar attribut : peminjam#, buku#, nama_peminjam, alamat_peminjam, judul, pengarang, penerbit, tgl_terbit, ISBN, harga_beli, harga_aktual, batas_pinjam, status_peminjam, tgl_pinjam, tgl_pesan.

• Beberapa attribut disini dapat berupa gabungan, seperti nama_peminjam dapat menjadi nama_keluarga dan panggilan.

Albertus Deliar/2006 - Perancangan Basis Data

115

LANGKAH 4 Tuliskan suatu daftar awal jenis entitas yang dapat diidentifikasikan langsung dan pilihlah identifier entitasnya. Untuk setiap jenis entitas, tuliskan suatu tabel hanya dengan identifiernya. • Berdasarkan skenario, identifier PEMINJAM# dan BUKU# dapat menunjukkan entitas yang mungkin dipilih yaitu Peminjam dan Buku. • Entitas yang mungkin lainnya dapat diseleksi pada tahapan ini, tetapi untuk sementara waktu digunakan dua entitas saja. • Tabel entitas yang dibentuk ialah : − Peminjam (peminjam#, …) − Buku (buku#, …)

Albertus Deliar/2006 - Perancangan Basis Data

116

LANGKAH 5a Gambarkan suatu diagram E-R yang menunjukkan relasi (relationship) antara semua jenis entitas, termasuk tingkat dan kelasnya secara detail. • Seorang peminjam dapat meminjam langsung beberapa buku tetapi sebuah buku tidak dapat dipinjam langsung oleh beberapa peminjam. • Sebuah buku tidak selalu dipinjam atau peminjam tidak selalu meminjam buku. • Diagram E-R ialah :

Albertus Deliar/2006 - Perancangan Basis Data

117

LANGKAH 5b (a)

(b)

Peminjam

Peminjam

1

m 1

Pinjam

n

Buku

n

Judul

Pesan Pinjam n 1 n

(c)

Peminjam

m 1

Albertus Deliar/2006 - Perancangan Basis Data

Pesan

Buku Judul 1 Sedia

Pinjam n 1

n Buku 1 118

LANGKAH 6a Buatlah suatu pemeriksaan awal dimana diagram E-R akan mendukung transaksi-transaksi, dan perbaikilah diagram jika perlu. Meskipun atribut-attribut belum dialokasikan ke entitas dan relasinya, hal ini tetap mungkin untuk memperoleh ide dimana transaksi dapat didukung pada tingkat entitas/relasinya. Lihat juga perangkap yang dapat terjadi. • Transaksi a, b, e dan f muncul menjadi penyedia bagi pembuatan dan penghapusan kejadian pada Peminjam dan Buku, dan peminjaman (transaksi c dan d) dapat diproses melalui relasi Pinjam (kenyataannya pemrosesan tidaklah sesederhana ini, secara terperinci akan diberikan pada langkah 11). Albertus Deliar/2006 - Perancangan Basis Data

119

LANGKAH 6b • Harga aktual mungkin menjadi attribut dari Buku, maka transaksi i dapat ditangani. Informasi yang dibutuhkan untuk pesan lewat batas waktu peminjaman (transaksi j) dapat ditemukan melalui Buku, Pinjam dan Peminjam. • Permasalahan yang tertinggal ialah untuk pemesanan (transaksi g dan h). Seorang peminjam dapat meminta beberapa pesanan dan buku yang sama dapat dipesan oleh beberapa peminjam, suatu model berdasarkan Gb. a. dapat berisikan suatu repeating groups. Pada pemunculan pertama, solusinya ialah dengan menambahkan relasi Pesan antara Peminjam dan Buku, tetapi ini tidak cukup karena seorang peminjam tidaklah memesan buku melainkan judul. Jika terdapat beberapa buku untuk satu judul maka tidak menjadi masalah buku mana yang akan diberikan. Albertus Deliar/2006 - Perancangan Basis Data

120

LANGKAH 6c • Kekeliruan diagram E-R ini untuk mendukung transaksi pemesanan memberi arti suatu kebingungan yang mendasar pada skenario dalam membedakan buku dan judul. Bukanlah judul yang dipinjamkan melainkan buku. Diagram dapat diperbaiki dengan memperkenalkan entitas Judul dan relasi Pesan (Gb. b), tetapi ini membuat sebuah perangkap hubungan antara Buku dan Judul. • Pada saat buku dikembalikan peminjam, maka sangat penting untuk memeriksa apakah seseorang telah memesan judul dari buku tersebut, maka perangkap hubungan ini harus dieliminir. Hal ini dapat diselesaikan dengan menghubungkan Judul ke Buku melalui relasi Sedia (Gb. c). Diasumsikan bahwa Judul dapat diidentifikasikan dengan ISBN. Albertus Deliar/2006 - Perancangan Basis Data

121

LANGKAH 7 Mengembangkan tabel entitas (langkah 4) ke tabel skeleton dengan memperhatikan diagram E-R. Hapus semua attribut yang dipakai sebagai identifier tabel skeleton dari daftar attribut. Tabel kerangka ialah : • Tabel entitas − Peminjam (peminjam#, …) − Buku (buku#, ISBN, …) − Judul (ISBN, …)

• Tabel relasi − Pinjam (buku#, peminjam#, …) − Pesan (peminjam#, ISBN, …)

• Relasi Pesan direpresentasikan dengan memasangkan (posted) ISBN ke Buku. Albertus Deliar/2006 - Perancangan Basis Data

122

LANGKAH 8a Tambahkan attribut selanjutnya dari daftar attribut ke tabel dengan memperhatikan syarat suatu tabel. Hapuslah attribut dari daftar attribut untuk setiap attribut yang dipasangkan ke tabel. Penyerahan attribut : •Peminjam (peminjam#, nama_peminjam, alamat_peminjam) •Buku (buku#, ISBN, harga_beli) •Judul (ISBN, judul, tgl_terbit, harga_aktual) •Pinjam (buku#, peminjam#, tgl_pinjam) •Pesan (peminjam#, ISBN, tgl_pesan) Berlawanan dengan asumsi pada langkah 6, harga_aktual bukanlah attribut untuk Buku. Albertus Deliar/2006 - Perancangan Basis Data

123

LANGKAH 8b • Catatan, jika batas_pinjam dinyatakan sebelum status_peminjam maka akan diletakkan ke dalam Peminjam tetapi berikutnya akan ditarik kembali mengikuti usaha pernyataan status_peminjam karena kondisi akhir akan menjadi penentu batas_pinjam tetapi tidak merupakan kandidat identifier dari Peminjam. • Untuk alasan yang sama, kedua attribut ini akan juga dikembalikan ke daftar attribut jika status_peminjam berada dengan batas_pinjam. • Asumsikan bahwa hanya ada satu penerbit yang disimpan di setiap judul, ini akan mengundang peletakkan penerbit ke tabel Judul.

Albertus Deliar/2006 - Perancangan Basis Data

124

LANGKAH 8c • Kebingungan dengan ISBN adalah kode_penerbit dimana akan menjadi penentu dari penerbit tetapi bukan kandidat identifier dari Judul. • Tabel Buku tidak menyediakan suatu tempat yang nyaman walaupun BUKU# adalah determinan dari penerbit karena nilai penerbit dapat redundant jika terdapat beberapa buku dari judul yang sama. • Penerbit harus tetap pada daftar attribut untuk semetara waktu.

Albertus Deliar/2006 - Perancangan Basis Data

125

LANGKAH 9a Jika terdapat attribut dari daftar attribut yang tidak dapat dipasangkan ke dalam tabel maka perlu dibentuk entitas atau relasi baru yang dapat mengakomodasikannya (perluasan model kerangka). Adakalanya hal tersebut tidak/sukar dilakukan maka ulangilah dari langkah 5. • Attribut yang belum dipasangkan ialah nama pengarang, status_peminjam, batas_pinjam dan penerbit. • Pengarang tidak diletakkan ke Judul karena akan menimbulkan repeating group. Jika tidak diperlukan untuk menyimpan berbagai attribut pengarang lainnya selain nama pengarang tersebut maka cukup untuk memperkenalkan Pengarang sebagai sub-entitas dari Judul. Albertus Deliar/2006 - Perancangan Basis Data

126

LANGKAH 9b • Untuk alasan yang diberikan pada langkah 8, attribut status_peminjam dan batas_pinjam tidak dapat keduanya diletakkan pada Peminjam. Suatu entitas baru, Limit, diperlukan. • Penerbit dapat dipasangkan dengan membentuk entitas baru yaitu Terbitan yang diidentifikasi dengan kode_penerbit. Entitas ini dihubungkan ke Judul melalui relasi Terbit. − Peminjam (peminjam#, nama_peminjam, alamat_peminjam, status_peminjam) − Buku (buku#, ISBN, harga_beli) − Judul (ISBN, judul, tgl_terbit, harga_aktual) − Limit (status_peminjam, batas_pinjam) − Pengarang (ISBN, pengarang) − Terbitan (kode_penerbit, penerbit) − Pinjam (buku#, peminjam#, tgl_pinjam) − Pesan (peminjam#, ISBN, tgl_pesan) Albertus Deliar/2006 - Perancangan Basis Data

127

LANGKAH 9c Limit

1 Terbita n

Terbit

1 n n

Atur n

m

Pesan

Tulis

1

Peminjam

Sedia

1

n Pengaran g

n 1

Pinjam n

Albertus Deliar/2006 - Perancangan Basis Data

Judul

1

Buku

128

LANGKAH 10 Putuskanlah jika terdapat attribut atau transaksi lainnya yang harus dimasukkan ke dalam model atau akan dikembangkan di kemudian hari. Jika ada, masukkan ke daftar attribut dan transaksi serta ulangi ke langkah 6 untuk transaksi baru dan langkah 8 untuk attribut baru. Transaksi lainnya yang termasuk untuk dipertimbangkan ialah : 1. Penyimpanan detail dari buku baru 2. Penghapusan buku 3. Pemberitahuan peminjam bahwa pemesanan saat ini dalam persediaan 4. Perubahan status peminjam 5. Menemukan buku dari seorang pengarang Albertus Deliar/2006 - Perancangan Basis Data

129

LANGKAH 11a Periksalah bahwa entitas yang dipilih, relasinya dan attribut tetap terlihat terpasang. Periksalah bahwa tabel telah normal penuh. Periksalah bahwa semua transaksi dapat didukung pada tingkat attribut. Jika diperlukan perubahan, ulangi prosedur. Pemeriksaan semua transaksi dapat dilakukan dengan cara sebagai berikut :

Albertus Deliar/2006 - Perancangan Basis Data

130

LANGKAH 11b  D – delete (penghapusan)  R – retrieve (pengambilan)  S – store (penyimpanan)  U – update (pembaharuan)

Albertus Deliar/2006 - Perancangan Basis Data

131

LANGKAH 12 Hapus semua entitas yang superfluous. • Setiap tabel entitas berisikan setidaknya satu attribut sebagai identifier-nya maka tidak ada tabel yang superfluous. • Jika Pengarang, yang diidentifikasikan dengan pengarang, dipilih sebagai sebuah entitas maka tabel Pengarang sebaiknya saat ini dipikirkan mengandung superfluous, jika hanya berisikan nama pengarang saja.

Albertus Deliar/2006 - Perancangan Basis Data

132

KOMENTAR AKHIR :  Pada saat bekerja dari skenario, sebaiknya menggarisbawahi pemilihan entitas, relasi dan attribut dengan warna yang berbeda untuk setiap kategori.  Sebaiknya memulai dengan 2 entitas saja, tidak perlu dengan banyak entitas sekaligus. Seringkali terjadi kesalahan dalam menginterpretasikan entitas.

Albertus Deliar/2006 - Perancangan Basis Data

133

AKHIR PERKULIAHAN GD2131 SISTEM BASIS DATA

Oleh: Albertus Deliar

KK. Inderaja dan SIG Fakultas Teknik Sipil dan Lingkungan Institut Teknologi Bandung 2006