P. 1
E-R

E-R

|Views: 100|Likes:
Dipublikasikan oleh Bangkit Adhi Nugraha

More info:

Published by: Bangkit Adhi Nugraha on Sep 12, 2012
Hak Cipta:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

10/13/2015

pdf

text

original

Sections

  • ENTITAS
  • CONTOH MODEL ER
  • JENIS ENTITAS & PEMUNCULANNYA
  • DERAJAT HUBUNGAN/RELASI
  • DERAJAT 1:1
  • DERAJAT 1:BANYAK / BANYAK:1
  • DERAJAT BANYAK:BANYAK
  • DIAGRAM ER & DERAJAT RELASI
  • KELAS KEANGGOTAAN
  • CONTOH OBL/OBL
  • CONTOH NON_OBL-NON_OBL
  • CONTOH OBL-NON_OBL
  • TABEL SKELETON (KERANGKA) ER
  • REPRESENTASI HUBUNGAN 1:1
  • DERAJAT 1:1 / KELAS OBL-OBL
  • TABEL SKELETON 1:1/OBL-OBL
  • DERAJAT 1:1 / KELAS OBL-NON_OBL
  • TABEL SKELETON 1:1/OBL-NON_OBL
  • REPRESENTASI HUBUNGAN 1:n
  • DERAJAT 1:n / KELAS OBL-OBL
  • TABEL SKELETON 1:n/OBL-OBL
  • DERAJAT 1:n / KELAS OBL-NON_OBL
  • TABEL SKELETON 1:n/OBL-NON_OBL
  • DERAJAT 1:n / KELAS NON_OBL-OBL
  • TABEL SKELETON 1:n/NON_OBL-OBL
  • DERAJAT 1:n / KELAS NON-NON
  • TABEL SKELETON 1:n/NON-NON
  • REPRESENTASI HUBUNGAN m:n
  • DERAJAT m:n
  • TABEL SKELETON m:n
  • DEKOMPOSISI BANYAK-BANYAK
  • PERANGKAP RELASI
  • PERANGKAP KIPAS (FAN TRAP)
  • HASIL INTERPRETASI
  • INTERPRETASI DAN DIAGRAM
  • DEFINISI
  • LEVEL DESIGN
  • CONTOH SKENARIO PERPUSTAKAAN
  • LANGKAH 1
  • LANGKAH 2
  • LANGKAH 3
  • LANGKAH 4
  • LANGKAH 5a
  • LANGKAH 5b
  • LANGKAH 6a
  • LANGKAH 6b
  • LANGKAH 6c
  • LANGKAH 7
  • LANGKAH 8a
  • LANGKAH 8b
  • LANGKAH 8c
  • LANGKAH 9a
  • LANGKAH 9b
  • LANGKAH 9c
  • LANGKAH 10
  • LANGKAH 11a
  • LANGKAH 11b
  • LANGKAH 12
  • KOMENTAR AKHIR :

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

1

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 Attribut … Attribut n

Albertus Deliar/2006 - Proses Entity Relationship

2

MODEL ENTITY RELATIONSHIP
 Entity/ Entitas  Attribut : a thing (object, concept) : a property of an entity

 Relationship

: an association between two (or more) entities

Entitas kendaraan darat !!!

Propertinya ???

Albertus Deliar/2006 - Proses Entity Relationship

3

• Entitas Mahasiswa memiliki ID Entitas NIM • Entitas Dosen memiliki ID Entitas NIP Diskusi: Apa perbedaan ID entitas dan ID tabel? Albertus Deliar/2006 .  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.Proses Entity Relationship 4 .ENTITAS  Setiap entitas memiliki anggota entitas.

Proses Entity Relationship 5 .CONTOH MODEL ER Entitas komputer & Propertinya?? Entitas harddisk & Propertinya?? Hubungan keduanya ?? Albertus Deliar/2006 .

… SIMPAN BARANG B4 Printer B2 Scanner B5 Plotter B3 Harddisk GUDANG G1 Jakarta G2 Bandung Albertus Deliar/2006 . G2 Bandung. Produk : menyimpan  Attribut : G1 Jakarta.Proses Entity Relationship 6 .JENIS ENTITAS & PEMUNCULANNYA  Entitas  Relasi : Gudang. P2 Printer.

DIAGRAM ENTITY RELATIONSHIP (ER)  Menggambarkan hubungan semua entitas.  Dalam diagram.Proses Entity Relationship 7 . dituliskan juga derajat dan kelas keanggotaan (dibahas kemudian) GUDANG SIMPAN BARANG Relasi Albertus Deliar/2006 .

DERAJAT HUBUNGAN/RELASI  Menunjukkan hubungan antar anggota dari suatu entitas terhadap anggota dari entitas lainnya. anggota entitas cukup diwakili oleh ID entitas saja.  Derajat hubungan ditentukan dari enterprise rules.  Secara mudah dapat diketahui melalui diagram pemunculannya. GUDANG G1 G2 SIMPAN BARANG B4 B2 B3 Albertus Deliar/2006 . Dalam menggambarkan diagram pemunculannya.Proses Entity Relationship 8 .

Albertus Deliar/2006 .Proses Entity Relationship 9 .DERAJAT 1:1  Enterprise Rules : • Seorang dosen (hampir selalu) mengajar satu matakuliah. 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 (hampir selalu) diajar oleh satu dosen. • Satu mata-kuliah secara pasti 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.Proses Entity Relationship 10 . • Satu mata-kuliah secara pasti diajar oleh satu dosen. Albertus Deliar/2006 .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 Albertus Deliar/2006 . • Satu mata-kuliah kemungkinan diajar oleh banyak dosen.Proses Entity Relationship 11 .DERAJAT BANYAK:BANYAK  Enterprise Rules : • Seorang dosen kemungkinan mengajar banyak matakuliah.

DOSEN 1 AJAR 1 KULIAH 1:1 DOSEN 1 AJAR n KULIAH 1:n DOSEN m AJAR n KULIAH m:n Albertus Deliar/2006 .Proses Entity Relationship 12 .DIAGRAM ER & DERAJAT RELASI  Derajat relasi digambarkan dalam diagram ER.

Albertus Deliar/2006 .  Kelas keanggotaan: • OBLIGATORY / OBL (wajib): Jika semua anggota entitas secara pasti berhubungan dengan anggota entitas lainnya.KELAS KEANGGOTAAN  Menunjukkan apakah semua anggota entitas memiliki hubungan dengan anggota entitas lagi secara pasti atau tidak.Proses Entity Relationship 13 . • NON-OBLIGATORY / NON_OBL : Jika tidak semua anggota entitas secara pasti berhubungan dengan anggota entitas lainnya.

Departemen kerja Karyawan  Anggota kedua entitas tersebut secara pasti berhubungan sehingga keduanya memiliki kelas obligatory Albertus Deliar/2006 .CONTOH OBL/OBL  Enterprise rules: • Satu Departemen harus mempekerjakan paling tidak satu Karyawan. • Seorang Karyawan harus dipekerjakan paling tidak oleh satu Departemen.Proses Entity Relationship 14 .

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 15 .CONTOH NON_OBL-NON_OBL  Enterprise rules: • Satu Departemen tidak perlu mempekerjakan seorang Karyawan-pun. • Seorang Karyawan tidak perlu dipekerjakan oleh Departemen manapun.

• Seorang Karyawan harus dipekerjakan paling tidak oleh satu Departemen.  Sebaliknya untuk entitas Karyawan sehingga berkelas obligatory Albertus Deliar/2006 .Proses Entity Relationship 16 .CONTOH OBL-NON_OBL  Enterprise rules: • Satu Departemen tidak perlu mempekerjakan seorang Karyawan-pun. Departemen kerja Karyawan  Anggota entitas Departemen tidak selalu memiliki hubungan dengan anggota entitas Karyawan sehingga memiliki kelas non-obligatory.

tentang keterkaitan attribut-attribut. Albertus Deliar/2006 .  Informasi tambahan tersebut.TABEL SKELETON (KERANGKA) ER  Diagram E-R digunakan untuk menggambarkan berbagai unsur penting dari model konseptual. dapat direpresentasikan dalam bentuk tabel normal penuh.Proses Entity Relationship 17 . tetapi tidak menunjukkan atribut-attribut yang berhubungan dengan entitas dan jenis hubungannya (relationship).  Representasi jenis tabel untuk setiap entitas dan jenis relasinya yang berupa tabel normal penuh (belum berisi attribut lainnya) disebut tabel skeleton ER.

Proses Entity Relationship 18 .  Representasi entitas dalam bentuk tabel: • Entitas Dosen (NIP.  Setiap dosen dapat diidentifikasi melalui NIP. …) Albertus Deliar/2006 . …) • Entitas Kuliah (Kode_MK. • Satu mata-kuliah maksimal dapat diajar oleh satu dosen.  Setiap mata kuliah dapat diidentifikasi dengan Kode_MK  Kondisi ini menggambarkan derajat relasi 1:1.REPRESENTASI HUBUNGAN 1:1  Ada ketentuan tentang dosen dan mata kuliah: • Seorang dosen maksimal dapat mengajar satu matakuliah.

DOSEN 130 000 001 130 000 002 130 000 003 130 000 004 AJAR KULIAH GD3333 GD4444 GD2222 GD1111 DOSEN 1 AJAR 1 KULIAH Albertus Deliar/2006 .Proses Entity Relationship 19 . • Satu mata-kuliah selalu diajar oleh satu dosen.DERAJAT 1:1 / KELAS OBL-OBL  Enterprise rules: • Seorang dosen selalu mengajar satu mata-kuliah.

…) Albertus Deliar/2006 . …. Dengan kata lain.  Terbentuk 1 tabel: • Tabel Dosen_Kuliah (NIP.Proses Entity Relationship 20 . Kode_MK. atau sebaliknya. attribut entitas Dosen dapat dipasangkan (posted) ke dalam attribut entitas Kuliah.TABEL SKELETON 1:1/OBL-OBL  Karena keduanya obligatory maka kedua entitas tersebut dapat digabungkan membentuk 1 tabel normal penuh.

DOSEN 130 000 001 130 000 002 130 000 003 130 000 004 130 000 005 AJAR KULIAH GD3333 GD4444 GD2222 GD1111 DOSEN 1 AJAR 1 KULIAH Albertus Deliar/2006 .DERAJAT 1:1 / KELAS OBL-NON_OBL  Enterprise rules: • Seorang dosen dapat mengajar satu mata-kuliah atau tidak.Proses Entity Relationship 21 . • Satu mata-kuliah selalu diajar oleh satu dosen.

…) • Tabel Kuliah (Kode_MK.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. …. NIP) Albertus Deliar/2006 .  Terbentuk 2 tabel: • Tabel Dosen (NIP.Proses Entity Relationship 22 .

DERAJAT 1:1 / KELAS NON_OBL-NON_OBL  Enterprise rules: • Seorang dosen dapat mengajar satu mata-kuliah atau tidak.Proses Entity Relationship 23 . • Satu mata-kuliah tidak selalu diajar oleh dosen. DOSEN 130 000 001 130 000 002 130 000 003 130 000 004 130 000 005 AJAR KULIAH GD3333 GD4444 GD2222 GD1111 GD5555 DOSEN 1 AJAR 1 KULIAH Albertus Deliar/2006 .

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

…) • Entitas Kuliah (Kode_MK. …) Albertus Deliar/2006 .  Setiap mata kuliah dapat diidentifikasi dengan Kode_MK  Kondisi Dosen:Kuliah menggambarkan derajat relasi 1:n.Proses Entity Relationship 25 . • Satu mata-kuliah maksimal dapat diajar oleh satu dosen.  Setiap dosen dapat diidentifikasi melalui NIP.  Representasi entitas dalam bentuk tabel: • Entitas Dosen (NIP.REPRESENTASI HUBUNGAN 1:n  Ada ketentuan tentang dosen dan mata kuliah: • Seorang dosen dapat mengajar lebih dari satu matakuliah.

DOSEN 130 000 001 130 000 002 130 000 003 AJAR KULIAH GD3333 GD4444 GD2222 GD1111 DOSEN 1 AJAR n KULIAH Albertus Deliar/2006 .DERAJAT 1:n / KELAS OBL-OBL  Enterprise rules: • Seorang dosen selalu mengajar satu atau lebih matakuliah.Proses Entity Relationship 26 . • Satu mata-kuliah selalu diajar oleh satu dosen.

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

DOSEN 130 000 001 130 000 002 130 000 003 AJAR KULIAH GD3333 GD4444 GD2222 GD1111 GD5555 n DOSEN 1 AJAR KULIAH Albertus Deliar/2006 . • Satu mata-kuliah dapat atau tidak diajar oleh satu dosen.DERAJAT 1:n / KELAS OBL-NON_OBL  Enterprise rules: • Seorang dosen selalu mengajar satu atau lebih matakuliah.Proses Entity Relationship 28 .

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

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. DOSEN 130 000 001 130 000 002 130 000 003 130 000 004 AJAR KULIAH GD3333 GD4444 GD2222 GD1111 DOSEN 1 AJAR n KULIAH Albertus Deliar/2006 .Proses Entity Relationship 30 .

NIP) Albertus Deliar/2006 .  Terbentuk 2 tabel: • Tabel Dosen (NIP.Proses Entity Relationship 31 .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’. …) • Tabel Kuliah (Kode_MK. ….

DOSEN 130 000 001 130 000 002 130 000 003 130 000 004 AJAR KULIAH GD3333 GD4444 GD2222 GD1111 GD5555 n DOSEN 1 AJAR KULIAH Albertus Deliar/2006 .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.Proses Entity Relationship 32 .

…) Albertus Deliar/2006 . Kode_MK) • Tabel Kuliah (Kode_MK.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.Proses Entity Relationship 33 .

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

• Satu mata-kuliah dapat diajar oleh satu atau lebih dosen.DERAJAT m:n  Enterprise rules: • Seorang dosen dapat mengajar satu atau lebih matakuliah.Proses Entity Relationship 35 . DOSEN 130 000 001 130 000 002 130 000 003 130 000 004 AJAR KULIAH GD3333 GD4444 GD2222 GD1111 GD5555 n DOSEN m AJAR KULIAH Albertus Deliar/2006 .

 Terbentuk 3 tabel: • Tabel Dosen (NIP.Proses Entity Relationship 36 .TABEL SKELETON m:n  Karena jeduanya berderajat banyak-banyak maka perlu dibentuk tabel penghubung. Kode_MK) • Tabel Kuliah (Kode_MK. …) Albertus Deliar/2006 . …) • Tabel Dosen-Kuliah (NIP.

karena hubungan m:n akan membentuk 3 tabel.  Hal ini dikarenakan adanya beberapa SMBD yang tidak mampu menangani relasi m:n.DEKOMPOSISI BANYAK-BANYAK  Merupakan pemisahan relasi m:n menjadi dua relasi 1:n.Proses Entity Relationship .  Jika dilakukan proses entity relationship. DOSEN 1 m AJAR n n KULIAH 1 DOSEN Dosen_Kuliah n KULIAH 37 Albertus Deliar/2006 . maka dekomposisi tersebut secara pasti dilakukan.

 Dikumpulkan pada kuliah berikutnya.TUGAS  Buatlah review tentang proses pembentukan tabel skeleton ER untuk semua kombinasi derajat dan kelas. dan harus berupa narasi serta di tulis tangan.  Berikan juga alasan mengapa tabel yang terbentuk harus demikian. Contoh.  Review ini tidak boleh sama dengan bahan transparansi yang ada. Albertus Deliar/2006 . baik tulisan maupun contoh.Proses Entity Relationship 38 . pada derajat 1:1 dan kelas non_obl-non_obl harus terbentu 3 tabel. mengapa tidak 2 tabel? Berikan alasan dan juga ilustrasinya.

5. Makanan adalah yang dimakan penjaga. Dari gambar diatas. Makanan adalah yang dimakan hewan.  Perangkap ini biasanya muncul akibat salah interpretasi dalam mengartikan relasi (relationship). Hewan menyukai makanan. apakah interpretasi yang dapat diberikan (pilih) : 1. 6.Proses Entity Relationship 39 . 3. Penjaga mengawasi hewan. 2.PERANGKAP RELASI  Merupakan perangkap yang adakalanya dijumpai oleh perancang & pemakai model konseptual yang harus dihilangkan. Makanan yang diawasi oleh penjaga. Albertus Deliar/2006 . Hewan diberi makan penjaga. 4.

 Sebagai contoh : • Dari gambar (a) dibentuk hubungan Departemen ke Pekerja melalui Divisi yang sangat mungkin dalam menyimpulkan pekerja mana dimiliki oleh departemen mana.PERANGKAP KIPAS (FAN TRAP)  Sering muncul pada bentuk relasi n:1-1:n. 1 Termasuk dept Divisi 1 Termasuk pek n Departeme n n Pekerja (a) Diskusi: Apa enterprise yang dapat diambil dari diagram diatas? Albertus Deliar/2006 .Proses Entity Relationship 40 .

DEPARTEMEN A B C D 2 1 Termasuk dept DIVISI Termasuk pek PEKERJA P1 P2 P3 P4 (b) P5 Diskusi: Bagaimana diagram yang seharusnya dari hasil interpretasi? Albertus Deliar/2006 . • Hal yang mungkin terpikirkan ialah pekerja dimiliki oleh divisi tetapi bukan departemen. 2.HASIL INTERPRETASI • Dari gambar b memperlihatkan kesimpulan tersebut tidak dapat terjadi karena tidak ada cara untuk mengetahui pekerja 1.Proses Entity Relationship 41 . 3 dimiliki oleh departemen 1 atau 2.

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 Divisi Termasuk dept Termasuk pek n Pekerja (c)  Pemahaman tentang enterprise yang ada harus benar-benar dimengerti agar tidak salah dalam menginterpretasikannya ke bentuk struktur relasi. Albertus Deliar/2006 .Proses Entity Relationship 42 .

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

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

Proses Entity Relationship 45 .PERANCANGAN BASIS DATA  Materi: • Desain Tingkat 1 (1st level design) Albertus Deliar/2006 .

yaitu bentuk transaksi yang akan dioperasikan. Albertus Deliar/2006 .  Mencakup : • Analisis data. • Analisis fungsional. yaitu kepemilikan data yang dibutuhkan untuk analisis.1ST LEVEL DESIGN  Digunakan karena rancangan akan dibutuhkan untuk pekerjaan selanjutnya dalam mentransformasikan desain ke implementasi akhir.Perancangan Basis Data 46 .

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

• Diagram ini digambarkan secara sederhana untuk membantu pemikiran awal tentang data yang dibutuhkan. Albertus Deliar/2006 . atau • Gambarkan secara singkat (sketsa) permasalahan.Perancangan Basis Data 48 .LANGKAH 1 Sketsalah permasalahan dengan diagram E-R secara bebas.

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

batas_pinjam. • Menyusun suatu daftar attribut : peminjam#. tgl_pinjam. • Beberapa attribut disini dapat berupa gabungan. harga_aktual. buku#. tgl_terbit. status_peminjam. Albertus Deliar/2006 . nama_peminjam. penerbit. alamat_peminjam. seperti nama_peminjam dapat menjadi nama_keluarga dan panggilan. tgl_pesan. harga_beli.LANGKAH 3 Persiapkan suatu daftar awal atribut.Perancangan Basis Data 50 . ISBN. judul. pengarang.

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

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

LANGKAH 5b (a) Peminjam 1 Pinjam n n (b) Peminjam m 1 Buku Judul Pesan Pinjam n 1 n Buku Judul 1 Sedia Pinjam n 1 n Buku 1 53 (c) Peminjam m 1 Pesan Albertus Deliar/2006 .Perancangan Basis Data .

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

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

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

Albertus Deliar/2006 . …) • Tabel relasi − Pinjam (buku#. peminjam#.LANGKAH 7 Mengembangkan tabel entitas (langkah 4) ke tabel skeleton dengan memperhatikan diagram E-R. …) − Buku (buku#. …) − Pesan (peminjam#.Perancangan Basis Data 57 . Hapus semua attribut yang dipakai sebagai identifier tabel skeleton dari daftar attribut. …) − Judul (ISBN. ISBN. Tabel kerangka ialah : • Tabel entitas − Peminjam (peminjam#. …) • Relasi Pesan direpresentasikan dengan memasangkan (posted) ISBN ke Buku. ISBN.

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 58

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

59

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

60

batas_pinjam dan penerbit. Adakalanya hal tersebut tidak/sukar dilakukan maka ulangilah dari langkah 5.Perancangan Basis Data 61 . status_peminjam. Jika tidak diperlukan untuk menyimpan berbagai attribut pengarang lainnya selain nama pengarang tersebut maka cukup untuk memperkenalkan Pengarang sebagai sub-entitas dari Judul. • Attribut yang belum dipasangkan ialah nama pengarang. Albertus Deliar/2006 . • Pengarang tidak diletakkan ke Judul karena akan menimbulkan repeating group.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).

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

Perancangan Basis Data 63 .LANGKAH 9c Limit 1 n Atur n Peminjam 1 Pinjam n m Pesan n Judul 1 Sedia n 1 Buku n Pengaran g 1 Tulis Terbit 1 Terbita n Albertus Deliar/2006 .

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

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

LANGKAH 11b  D – delete (penghapusan)  R – retrieve (pengambilan)  S – store (penyimpanan)  U – update (pembaharuan) Albertus Deliar/2006 .Perancangan Basis Data 66 .

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

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

Inderaja dan SIG Fakultas Teknik Sipil dan Lingkungan Institut Teknologi Bandung 2006 .AKHIR PERKULIAHAN GD2131 SISTEM BASIS DATA Oleh: Albertus Deliar KK.

You're Reading a Free Preview

Mengunduh
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->