Entity-Relationship

Modelling (Bagian 2)
Dr. Rosa Delima, S.Kom., M.Kom.
Lukas Chrisantyo, S.Kom., M.Eng.
Agata Filiana, S.Kom., M. Sc.
Maria Nila Anggia Rini, S.T., M.T.I.
 Model
Logical-Physical
 Konseptual → Implementasi
› Diagram Crow’s Foot memiliki jenis tampilan yang cenderung lebih efisien
daripada Chen Notation.
› Atribut dituliskan dalam kotak entitas, dengan melengkapi informasi PK dan FK.
Belah ketupat relationship bisa ditiadakan.
› Diupayakan tidak ada lagi relationship many-to-many. Relationship ini hanya ada
dalam level konseptual dan untuk implementasinya karena sehubungan dengan
sifat kunci, maka perlu ada tindakan khusus.
› Semua M:N diubah menjadi 1:M dan M:1 dengan bantuan tambahan bridge table
atau entitas asosiatif.
› Demikian pula untuk relationship one-to-one, desainer harus memiliki
argumentasi yang kuat untuk mempertahankan relationship ini.
 Notasi ERD Crow’s Foot
Relationship dan Kardinalitasnya

• Mandatory = harus ada minimal satu

• Optional = boleh tidak ada
Implementasi Relasi Antar Tabel

menjadi paints
 Implementasi Atribut Komposit
▸ Implementasikan konsep atribut komposit menjadi ERD Crow’s Foot cukup
mudah. Kita bisa menggantikan langsung sub-atribut komposit menjadi atribut
yang setara dengan atribut-atribut lain.

menjadi
 Implementasi Atribut Multivalued
Ada dua solusi:
1. Apabila jumlah nilai atributnya terukur (tidak dinamis) dapat
menggunakan cara implementasi atribut komposit.
2. Apabila jumlah nilai atributnya tidak terukur, bisa berbeda-beda
tergantung kondisi, maka harus dibuatkan tabel baru.
Untuk contoh atribut telepon dapat menggunakan solusi (1) apabila jumlah
nilainya dibatasi misalnya hanya dua.
Sedangkan untuk atribut pelanggaran, perlu dibuatkan tabel terpisah.
Implementasi Atribut Multivalued

Solusi implementasi atribut

telepon dan pelanggaran:
 Implementasi Atribut Harus Bernilai &
Atribut Turunan
ERD Crow’s Foot tidak ada notasi khusus untuk mengimplementasikan
atribut harus bernilai/not null. Desainer DB dapat melengkapi informasi not
null di data dictionary.

Demikian juga untuk mengimplementasikan atribut turunan. Desainer DB

dapat mempertimbangkan menambahkan informasi atribut tersebut
dengan bantuan trigger atau stored procedure, ataupun dihitung secara
“live” melalui sisi frontend dari aplikasi.
 Derajat
Relationship
 Derajat Relationship
Ada tiga macam:
1. Unary Relationship relationship yang hanya melibatkan satu tipe
entitas.
Contoh: Manager (employee) manages employees
Human married with human
 Derajat Relationship
2. Binary Relationship relationship
yang melibatkan dua tipe entitas.
Contoh ini sudah sering diulas.

3. Ternary Relationship
relationship yang melibatkan tiga
tipe entitas.
Kekuatan Relationship
 Kekuatan Relationship
› Konsep kekuatan relationship didasarkan pada bagaimana menentukan PK dari
tabel yang saling berhubungan.
› Ingat lagi bahwa PK dapat menjelma menjadi FK di tabel anak/referencing
relation.
› Secara default, relationship terjadi dengan membuat PK dari tabel induk
muncul sebagai FK di tabel anak.
› Ketika membuat dan mengisi tabel juga jangan lupa untuk selalu berurutan dari
tabel induk dahulu baru tabel anak.
 Relationship Kuat vs Lemah
› Strong (Identifying) Relationship
• Entitas anak keberadaannya bergantung pada entitas induk
• PK dari entitas anak berisi komponen PK dari entitas induk
• Umumnya membentuk composite key untuk PK-nya.
› Weak (Non-Identifying) Relationship
• Entitas anak keberadaannya tidak bergantung pada entitas induk
• PK dari entitas anak tidak berisi komponen PK dari entitas induk
Contoh Relationship Kuat
› Relationship Kuat, juga
disebut identifying
relationship, muncul saat PK
dari referencing relation/tabel
anak yang terhubung memiliki
komponen PK dari referenced
relation/tabel induk.
› Contoh di samping termasuk
relationship kuat karena tabel
mtkDitawarkan memiliki PK
komposit:
{idMtk, grup, semester, tahun}
Revisit Konten Tabel
Contoh Relationship Lemah
› Pada kasus ini relationship lemah
terjadi antara tabel matakuliah dan
tabel mtkDitawarkan karena
idMtkDitawarkan adalah PK dari tabel
mtkDitawarkan, sementara idMtk
hanya menjadi FK.
› PK dari tabel mtkDitawarkan tidak
“mewarisi” komponen PK dari tabel
matakuliah. Dapat berupa Surrogate
Key
› Cara menggambarkan relationship
lemah ini adalah dengan garis
putus-putus.
Revisit Konten Tabel
 Pro-Cons Kekuatan Relationship
▸ Menurut Anda?
Pro Kuat Con Kuat Pro Lemah Con Lemah
 Entitas Lemah
Entitas Asosiatif
 Entitas Lemah
› Entitas lemah adalah entitas yang memenuhi dua kondisi:
• Existence-dependent; entitas tidak bisa muncul tanpa entitas yang
terhubung dengannya.
• Entitas ini memiliki PK yang secara parsial atau keseluruhan diturunkan dari
entitas induknya.
› Contoh:
› mtkDitawarkan adalah entitas lemah terhadap matakuliah,
› dependent juga merupakan entitas lemah terhadap employee.
› Dengan kata lain entitas lemah = entitas anak.
Contoh Entitas Lemah
 Contoh Entitas Lemah
dalam Relationship Kuat
 Entitas Asosiatif (Bridge Table)
› Seperti yang sudah diungkapkan sebelumnya, usahakan kondisi akhir dari model
berada dalam relationship 1:M.
› Relationship 1:1 boleh terjadi, namun harus hati-hati dan diperhatikan
penggunaannya.
› Jika relationship M:N muncul, kita perlu membuat sebuah jembatan antar entitas
yang terikat pada relationship itu.
› Entitas asosiatif dipakai untuk mengimplementasikan relationship M:N antar dua
entitas atau lebih.
› Entitas asosiatif terdiri dari PK dari tiap entitas yang terhubung.
Contoh
Entitas
Asosiatif
› Pembendaan kata kerja:
mengambil > pengambilan

› Bisa menggunakan kata

lain yang lebih familiar
(“registrasi”)
 Entitas Asosiatif (Bridge Table)
› Pada contoh di slide sebelumnya, entitas asosiatif registrasi bersifat existence-
dependent terhadap dua entitas lainnya.
› Tabel registrasi juga tersusun atas composite PK dengan relationship kuat dari
masing-masing tabel mahasiswa dan mtkDitawarkan, serta ada kolom atribut
tambahan yang berisi nilai mata kuliah.
› Dalam kasus ini, otomatis tidak dimungkinkan ada entry null pada setiap atribut
kunci dari registrasi.
› Secara umum, nama entitas asosiatif didapat dari bentuk kata kerja yang
dibendakan (gerund). Contoh:
• Registrasi = dari “mengambil” menjadi “pengambilan”
• Peminjaman = dari “meminjam”
Berikan saya 2 pertanyaan…
 Small Group Discussion #5
› Buatlah ERD Crow’s Foot dengan jenis relationship kuat (kelompok ganjil) atau
relationship lemah (kelompok genap) berdasarkan pengerjaan SGD #4.
› Ada 2 kelompok yang menunjukkan hasilnya di papan tulis, sisanya dikerjakan
seperti SGD #4 di draw.io kemudian diekspor ke GSheet.
› Harus ada tanda kardinalitas partisipasi minimal-maksimal.
 Milestone 2 Tugas #1
› Tambahkan satu slide yang berisi daftar semua entitas yang ada, berdasarkan
hasil Milestone 1.

› Tambahkan satu slide yang berisi statemen relationship dengan format:

› Satu [entitas A] [kata kerja relationship aktif] dengan [satu/lebih dari satu]
[entitas B], dan satu [entitas B] [kata kerja relationship pasif] dengan
[satu/lebih dari satu] [entitas A].

› Mengawali statemen relationship dengan kata “Banyak” tidak akan direview.

› Dikumpulkan Jumat, 30 September 2022 pukul 23:59 WIB.