RMK SYSTEM MANAJEMEN DATABASE

RESKY ANDRIANI JALIL_A031171336

MODEL HUBUNGAN ENTITAS
Salah satu aspek yang paling sulit dari desain database adalah kenyataan bahwa desainer,
programmer, dan pengguna akhir cenderung melihat data dan penggunaannya dengan cara
yang berbeda. Sayangnya, kecuali kita memperoleh pemahaman umum yang mencerminkan
bagaimana perusahaan beroperasi, desain yang kami hasilkan akan gagal memenuhi
persyaratan pengguna. Untuk memastikan bahwa kami mendapatkan pemahaman yang tepat
tentang sifat data dan bagaimana data itu digunakan oleh perusahaan, kita memerlukan model
untuk komunikasi yang non-teknis dan bebas ambiguitas. Model Entity – Relationship (ER)
adalah salah satu contohnya. Pemodelan ER adalah pendekatan top-down untuk desain
database yang dimulai dengan mengidentifikasi data yang penting disebut entitas dan
hubungan antara data yang harus mewakili dalam model. Kami kemudian menambahkan
detail lebih lanjut, seperti informasi yang ingin kami simpan mengenai entitas dan hubungan
yang disebut atribut dan segala kendala pada entitas, hubungan, dan atribut. Pemodelan ER
adalah teknik penting untuk perancang basis data apa pun untuk menguasai dan membentuk
dasar metodologi yang disajikan .
12.1 Jenis Entitas
Jenis entitas Sekelompok objek dengan properti yang sama, yang diidentifikasi oleh
perusahaan yang memiliki keberadaan independen.
Konsep dasar model ER adalah tipe entitas, yang mewakili suatu kelompok "objek" di
"dunia nyata" dengan sifat yang sama. Tipe entitas memiliki keberadaan independen dan
dapat menjadi objek dengan keberadaan fisik (atau "nyata") atau objek dengan keberadaan
konseptual (atau "abstrak"), Perhatikan bahwa kita hanya dapat memberikan definisi kerja
dari jenis entitas, karena tidak ada definisi formal yang ketat. Hal ini berarti bahwa desainer
yang berbeda dapat mengidentifikasi entitas yang berbeda.
Kejadian entitas Objek unik yang dapat diidentifikasi dari jenis entitas.
Setiap objek unik yang dapat diidentifikasi dari jenis entitas disebut hanya sebagai
kejadian entitas. Sepanjang buku ini, kami menggunakan istilah "tipe entitas" atau "entitas
kejadian"; Namun, kami menggunakan istilah “entitas” yang lebih umum di mana artinya
sudah jelas.
Kami mengidentifikasi setiap jenis entitas dengan nama dan daftar properti. Database
biasanya mengandung banyak jenis entitas yang berbeda. Contoh tipe entitas meliputi: Staf ,
Cabang , PropertyForRent , dan PrivateOwner.
Representasi diagram tipe entitas
Setiap jenis entitas ditampilkan sebagai persegi panjang, dilabeli dengan nama entitas,
yang biasanya kata benda tunggal. Di UML, huruf pertama dari setiap kata dalam nama
entitas adalah huruf besar (misalnya, Staf dan PropertyForRent ).
12.2 Jenis Hubungan
Jenis hubungan Serangkaian asosiasi yang bermakna antara tipe-tipe entitas.
Tipe hubungan adalah seperangkat asosiasi antara satu atau lebih banyak jenis entitas
yang berpartisipasi. Setiap tipe hubungan diberi nama yang menjelaskan fungsinya. Contoh
dari jenis hubungan yang ditunjukkan adalah hubungan yang disebut POwns, yang
mengaitkan entitas PrivateOwner dan PropertyForRent.
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
Seperti halnya jenis entitas dan entitas, perlu untuk membedakan antara istilah "Tipe
hubungan" dan "kejadian hubungan."
Kejadian hubungan Asosiasi yang dapat diidentifikasi secara unik yang mencakup satu
kejadian dari setiap jenis entitas yang berpartisipasi.
Kejadian hubungan menunjukkan kejadian entitas tertentu yang terkait. Sepanjang buku
ini, kami menggunakan istilah "tipe hubungan" atau "kejadian hubungan". Namun, seperti
halnya istilah "entitas," kami menggunakan istilah yang lebih umum "Hubungan" ketika
artinya jelas.
Pertimbangkan jenis hubungan yang disebut Has, yang mewakili hubungan antara Entitas
Cabang dan Staf, yaitu Cabang Memiliki Staf. Setiap kemunculan hubungan Has-
mengaitkan hubungan satu kejadian entitas Cabang dengan satu kejadian entitas Staf. Kita
dapat memeriksa contoh-contoh kejadian individu dari hubungan Has menggunakan jaring
semantik. Jaring semantik adalah model tingkat objek, yang menggunakan simbol • untuk
mewakili entitas dan simbol ◊ untuk mewakili hubungan. Jaring semantik pada Gambar 12.4
menunjukkan tiga contoh hubungan Has (dilambangkan rl, r2, dan r3). Setiap hubungan
menggambarkan asosiasi dari kejadian entitas Cabang tunggal dengan kejadian entitas Staf
tunggal. Hubungan diwakili oleh garis-garis yang bergabung dengan setiap entitas Cabang
yang berpartisipasi dengan entitas Staf terkait. Sebagai contoh, hubungan rl mewakili
hubungan antara entitas Cabang B003 dan entitas Staf SG37.
Perhatikan bahwa kami mewakili setiap kejadian entitas Cabang dan Staf menggunakan
nilai untuk atribut kunci utama, yaitu branchNo dan staffNo. Atribut kunci utama secara unik
mengidentifikasi setiap kejadian entitas dan dibahas secara rinci dalam bagian selanjutnya.
Jika perusahaan menggunakan jaring semantik, akan sulit untuk mengerti, karena tingkat
detail. Kita bisa lebih mudah mewakili hubungan antara entitas dalam suatu perusahaan
menggunakan konsep model ER. Model ER menggunakan tingkat abstraksi yang lebih tinggi
daripada jaring semantik dengan menggabungkan seperangkat kejadian entitas menjadi jenis
entitas dan set kejadian hubungan menjadi jenis hubungan.

Representasi diagram dari tipe hubungan

Setiap tipe hubungan ditampilkan sebagai garis yang menghubungkan tipe entitas terkait
dan dilabeli dengan nama hubungan. Biasanya, suatu hubungan diberi nama menggunakan
kata kerja (misalnya, Pengawasan atau Mengelola ) atau frasa pendek termasuk kata kerja
(contohnya, LeasedBy ). Sekali lagi, huruf pertama dari setiap kata dalam nama hubungan
ditunjukkan dalam huruf besar. Bila memungkinkan, nama hubungan harus unik untuk model
ER yang diberikan.
Suatu hubungan hanya diberi label dalam satu arah, yang biasanya berarti bahwa nama
hubungan hanya masuk akal dalam satu arah (misalnya, Cabang Memiliki Staf lebih masuk
akal daripada Staf Memiliki Cabang ). Jadi, sekali nama hubungan itu dipilih, simbol panah
ditempatkan di sebelah nama yang menunjukkan arah yang benar bagi pembaca untuk
menafsirkan nama hubungan (misalnya, Cabang Memiliki ► Staf ) sebagai ditunjukkan pada
Gambar 12.5.
12.2.1 Tingkat Tipe Hubungan
Tingkat tipe hubungan Jumlah tipe entitas yang berpartisipasi dalam suatu hubungan.
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
Entitas yang terlibat dalam jenis hubungan tertentu disebut sebagai peserta dalam
hubungan tersebut. Jumlah peserta dalam tipe hubungan disebut derajat dari hubungan
tersebut. Oleh karena itu, derajat hubungan menunjukkan jumlah jenis entitas yang terlibat
dalam suatu hubungan. Hubungan tingkat dua adalah disebut biner. Contoh hubungan biner
adalah hubungan Has yang ditunjukkan dengan dua jenis entitas yang berpartisipasi; yaitu,
Staf dan Cabang. Contoh kedua hubungan biner adalah hubungan POwns yang ditunjukkan
dengan dua jenis entitas yang berpartisipasi; yaitu, PrivateOwner dan PropertyForRent.
Hubungan Has dan POwns juga ditunjukkan serta contoh-contoh lain dari hubungan biner.
Bahkan, tingkat paling umum untuk suatu hubungan adalah biner, seperti yang ditunjukkan
pada gambar ini.
Hubungan tingkat tiga disebut ternary. Contoh hubungan ternary adalah Register dengan
tiga jenis entitas yang berpartisipasi: Staf, Cabang, dan Klien. Hubungan ini merupakan
pendaftaran klien oleh anggota staf di cabang. Istilah "hubungan kompleks" digunakan untuk
menggambarkan hubungan dengan derajat lebih tinggi dari biner.
Representasi diagram dari hubungan yang kompleks
Notasi UML menggunakan berlian untuk mewakili hubungan dengan derajat yang lebih
tinggi dari biner. Nama hubungan ditampilkan di dalam berlian, dan dalam hal ini, arah panah
yang biasanya dikaitkan dengan nama dihilangkan. Sebagai contoh, hubungan ternary yang
disebut Register. Hubungan tingkat empat disebut kuaterner. Karena kita tidak punya contoh
hubungan seperti itu pada Gambar 12.1, kami menggambarkan hubungan kuartener yang
disebut Arranges dengan empat jenis entitas yang berpartisipasi — yaitu, Buyer, Solicitor,
Financiallnstitution, dan Bid- . Hubungan ini mewakili situasi di mana Buyer, disarankan
oleh pengacara dan didukung oleh institusi keuangan, tempatkan tawaran.
12.2.2 Hubungan Rekursif
Rekursif hubungan Jenis hubungan di mana jenis entitas yang sama berpartisipasi lebih
banyak dari sekali dalam berbagai peran.
Pertimbangkan hubungan rekursif yang disebut Supervises, yang mewakili asosiasi staf
dengan Supervises di mana Supervises juga merupakan anggota staf. Dengan kata lain, yang
jenis entitas Staf berpartisipasi dua kali dalam mengawasi hubungan; peserta pertama sebagai
pengawas, dan partisipasi kedua sebagai anggota staf yang diawasi (Pengawas). Hubungan
rekursif kadang-kadang disebut hubungan unary .
Hubungan dapat diberi nama peran untuk menunjukkan tujuan yang masing-masing
peserta tipe entitas bermain dalam suatu hubungan. Nama peran bisa menjadi penting untuk
hubungan rekursif untuk menentukan fungsi masing-masing peserta. Penggunaan nama peran
untuk menggambarkan hubungan rekursif Supervises. Partisipasi pertama dari jenis entitas
Staf dalam hubungan Pengawas diberi nama peran "Pengawas" dan partisipasi kedua diberi
nama peran "Pengawas."
Nama peran juga dapat digunakan ketika dua entitas dikaitkan melalui lebih banyak dari
satu hubungan. Misalnya, tipe entitas Staf dan Cabang terkait melalui dua hubungan berbeda
yang disebut Mengelola dan Memiliki. Seperti yang ditunjukkan, penggunaan nama-nama
peran menjelaskan tujuan dari setiap hubungan. Misalnya, dalam kasus Staf Mengelola
Cabang, anggota staf ( entitas Staf) diberi nama peran "Manajer" mengelola cabang ( entitas
Cabang ) yang diberi nama peran "Kantor Cabang." Demikian pula, untuk Branch Has Staff,
cabang, diberi nama peran "Branch Office" has staf diberi nama peran "Anggota Staf."Nama
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
peran biasanya tidak diperlukan jika fungsi entitas yang berpartisipasi dalam suatu hubungan
tidak ambigu.
12.3 Atribut
Atribut Properti entitas atau tipe hubungan.
Properti tertentu dari tipe entitas disebut atribut. Misalnya, sebuah jenis entitas Staf dapat
dijelaskan oleh atribut stafNo, nama, posisi, dan gaji. Atribut memiliki nilai yang
menggambarkan setiap kejadian entitas dan mewakili bagian utama dari data yang disimpan
dalam database.
Domain atribut Seperangkat nilai yang diizinkan untuk satu atau beberapa atribut.
Setiap atribut dikaitkan dengan satu set nilai yang disebut domain. Domain
mendefinisikan nilai potensial yang dimiliki suatu atribut dan mirip dengan konsep domain
dalam model relasional. Misalnya, jumlah kamar yang terkait dengan properti adalah antara 1
dan 15 untuk setiap kejadian entitas. Oleh karena itu, kami menetapkan seperangkat nilai
untuk jumlah atribut kamar (kamar) dari jenis entitas PropertyForRent sebagai himpunan
bilangan bulat antara 1 dan 15.
Atribut dapat membagikan domain. Misalnya, jenis entitas atribut address dari Branch,
PrivateOwner, dan BusinessOwner berbagi domain yang sama dari semua kemungkinan
alamat. Domain juga dapat terdiri dari domain. Misalnya saja domain untuk atribut alamat
entitas Cabang terdiri dari subdomain: jalan, kota, dan kode pos.
Domain atribut nama lebih sulit untuk didefinisikan, karena terdiri dari semua
kemungkinan nama. Hal ini tentu saja rangkaian karakter, tetapi mungkin tidak hanya terdiri
dari huruf tetapi juga tanda hubung atau karakter khusus lainnya. Model data yang
dikembangkan sepenuhnya termasuk domain setiap atribut dalam model ER.
Seperti yang sekarang kami jelaskan, atribut dapat diklasifikasikan sebagai: sederhana
atau gabungan, tunggal dihargai atau multi-dihargai, atau diturunkan.
12.3.1 Atribut Sederhana dan Komposit
Atribut sederhana Atribut yang terdiri dari satu komponen dengan keberadaan independen.
Atribut sederhana tidak dapat dibagi lagi menjadi komponen yang lebih kecil.
Contohnya atribut sederhana termasuk posisi dan gaji dari Staf entitas. Atribut sederhana
kadang-kadang disebut atribut atom.
Gabungan atribut Atribut yang terdiri dari beberapa komponen, masing-masing dengan
keberadaan independen.
Beberapa atribut dapat dibagi lagi untuk menghasilkan komponen yang lebih kecil
dengan keberadaan independen mereka sendiri. Misalnya, atribut alamat Cabang entitas
dengan nilai (163 Main St, Glasgow, G11 9QX) dapat dibagi lagi menjadi jalan (163 Main
St), atribut city (Glasgow), dan kode pos (G11 9QX).
Keputusan untuk memodelkan atribut alamat sebagai atribut sederhana atau untuk
membagi lagi atribut ke jalan, kota, dan kode pos tergantung pada apakah tampilan data
pengguna mengacu pada atribut alamat sebagai satu unit atau sebagai komponen individu.
12.3.2 Atribut bernilai Tunggal dan bernilai Banyak
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
Atribut bernilai tunggal Atribut yang memiliki nilai tunggal untuk setiap kemunculan suatu
jenis entitas.
Mayoritas atribut bernilai tunggal. Misalnya, setiap kemunculan Jenis entitas cabang
memiliki nilai tunggal untuk atribut nomor cabang ( branchNo ) (untuk contoh, B003), dan
oleh karena itu atribut branchNo disebut bernilai tunggal.
Atribut bernilai banyak Atribut yang menyimpan banyak nilai untuk setiap kemunculan
suatu jenis entitas.
Beberapa atribut memiliki beberapa nilai untuk setiap kejadian entitas. Misalnya
masing-masing kemunculan tipe entitas Cabang dapat memiliki beberapa nilai untuk atribut
telNo (misalnya, nomor cabang B003 memiliki nomor telepon 0141-339-2178 dan 0141-339-
4439) dan oleh karena itu atribut telNo dalam kasus ini bernilai banyak. Sebuah atribut
bernilai banyak mungkin memiliki satu set angka dengan batas atas dan bawah. Untuk
contoh, atribut telNo dari tipe entitas Cabang memiliki antara satu dan tiga nilai. Dengan kata
lain, cabang mungkin memiliki minimal satu nomor telepon hingga maksimal tiga nomor
telepon.
12.3.3 Asal Atribut
Asal Atribut Atribut yang mewakili nilai yang dapat diturunkan dari nilai atribut terkait atau
serangkaian atribut, tidak harus dalam jenis entitas yang sama.
Nilai-nilai yang dipegang oleh beberapa atribut dapat diturunkan. Misalnya, nilai
untuk yang durasi atribut entitas Lease dihitung dari RentStart dan rentFinish atribut, juga
dari tipe entitas Sewa. Kami merujuk ke atribut durasi sebagai atribut turunan, nilainya
diturunkan dari atribut rentStart dan rentFinish.
Dalam beberapa kasus, nilai atribut diturunkan dari kejadian entitas di jenis entitas
yang sama. Misalnya, jumlah total atribut staf ( totalStaff ) dari yang entitas Staf dapat
dihitung dengan menghitung jumlah total Staf entitas kejadian.
Atribut yang diturunkan juga dapat melibatkan asosiasi atribut dari jenis entitas yang
berbeda. Sebagai contoh, perhatikan atribut yang disebut deposito dari tipe entitas Lease.
Nilai atribut deposit dihitung dua kali sewa bulanan untuk sebuah properti. Oleh karena itu,
nilai atribut setoran dari tipe entitas Sewa berasal dari atribut sewa dari tipe entitas
PropertyForRent.
12.3.4 Kunci
Kunci kandidat Perangkat minimal dari atribut yang secara unik mengidentifikasi setiap
kejadian dari jenis entitas.
Kunci kandidat adalah jumlah minimal atribut, yang nilainya diidentifikasi secara
unik setiap kejadian entitas. Sebagai contoh, atribut nomor cabang ( branchNo ) adalah kunci
kandidat untuk jenis entitas Cabang , dan memiliki nilai yang berbeda untuk masing-
masingnya kejadian entitas cabang. Kunci kandidat harus memiliki nilai yang unik untuk
setiap kemunculan jenis entitas. Hal ini menyiratkan bahwa kunci kandidat tidak dapat berisi
sebuah null (lihat Bagian 4.2). Misalnya, setiap cabang memiliki nomor cabang yang unik
(misalnya, B003), dan tidak akan pernah ada lebih dari satu cabang dengan nomor cabang
yang sama.
Kunci utama Kunci kandidat yang dipilih untuk mengidentifikasi secara unik setiap kejadian
dari jenis entitas.
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
Jenis entitas mungkin memiliki lebih dari satu kunci kandidat. Untuk keperluan
diskusi, pertimbangkan bahwa anggota staf memiliki perusahaan yang unik-nomor staf yang
ditentukan (staffNo) dan juga Nomor Asuransi Nasional (NIN) unik yang digunakan oleh
pemerintah. Karena itu kami memiliki dua kunci kandidat untuk entitas Staf, satu yang harus
dipilih sebagai kunci utama.
Pilihan kunci utama untuk suatu entitas didasarkan pada pertimbangan panjang
atribut, jumlah minimal atribut yang diperlukan, dan kepastian keunikan dimasa depan.
Misalnya, perusahaan menentukan nomor staf yang maksimal berisi lima karakter (misalnya,
SG14), dan NIN berisi maksimum sembilan karakter (misalnya, WL220658D). Karenanya,
kami memilih staffNo sebagai kunci utama dari tipe entitas Staf dan NIN kemudian disebut
sebagai kunci alternatif.
Kunci komposit Kunci kandidat yang terdiri dari dua atribut atau lebih.
Dalam beberapa kasus, kunci dari tipe entitas terdiri dari beberapa atribut yang nilainya
unik secara bersama untuk setiap kejadian entitas tetapi tidak secara terpisah. Misalnya,
pertimbangkan entitas yang disebut Advert dengan propertyNo (nomor properti),
newspaperName, dateAdvert, dan atribut biaya. Banyak properti diiklankan di banyak surat
kabar pada tanggal tertentu. Untuk secara unik mengidentifikasi setiap kemunculan Jenis
entitas iklan memerlukan nilai untuk propertyNo, newspaperName, dan atribut dateAdvert.
Dengan demikian, jenis entitas Advert memiliki kunci primer gabungan yang terdiri dari
atribut propertyNo, newspaperName, dan dateAdvert .
Representasi atribut diagram
Jika jenis entitas ingin ditampilkan dengan atributnya, kami membagi persegi panjang
yang mewakili entitas menjadi dua. Bagian atas dari persegi panjang menampilkan nama
entitas dan bagian bawah mencantumkan nama atribut. Atribut pertama untuk didaftar adalah
kunci utama untuk tipe entitas, jika diketahui. Nama atribut kunci primer dapat dilabeli
dengan tag {PK}. Di UML, nama atribut ditampilkan dengan huruf pertama dalam huruf
kecil dan, jika nama tersebut memiliki lebih dari satu kata, dengan huruf pertama dari setiap
kata berikutnya dalam huruf besar (misalnya, alamat dan telno ). Tag tambahan yang dapat
digunakan termasuk kunci primer parsial {PPK} ketika atribut membentuk bagian dari kunci
primer komposit, dan tombol alternatif {AK}. Seperti yang ditunjukkan, kunci utama jenis
entitas Staf adalah atribut staffNo dan kunci utama dari jenis entitas Branch adalah atribut
branchNo.
Untuk beberapa sistem basis data yang lebih sederhana, dimungkinkan untuk
menunjukkan semua atribut setiap jenis entitas dalam diagram ER. Namun, untuk sistem
basis data yang lebih kompleks, kami hanya menampilkan atribut, atau atribut, yang
membentuk kunci utama dari setiap jenis entitas. Ketika hanya atribut kunci utama yang
ditampilkan dalam diagram ER, kita bisa hapus tag {PK}.
Untuk atribut sederhana dan bernilai tunggal, tidak perlu menggunakan tag, jadi kami
cukup tampilkan nama atribut dalam daftar di bawah nama entitas. Untuk atribut komposit,
kami mencantumkan nama dari atribut gabungan yang diikuti di bawah dan menjorok ke ke
kanan dengan nama atribut komponennya yang sederhana. Misalnya, atribut komposit alamat
dari Cabang entitas ditampilkan, diikuti di bawah dengan nama atribut komponennya, jalan,
kota, dan kode pos. Untuk atribut bernilai banyak, kami memberi label nama atribut dengan
indikasi rentang nilai tersedia untuk atribut. Misalnya, jika kita memberi label atribut telNo
dengan rentang [1 .. *], ini berarti bahwa nilai untuk atribut telNo adalah satu atau lebih. Jika
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
kita tahu jumlah nilai maksimum yang tepat, kita dapat memberi label atribut dengan jarak
tepat. Misalnya, jika atribut telNo menampung satu hingga maksimum tiga nilai, kita bisa
memberi label pada atribut dengan [1..3].
Untuk atribut turunan, kami awali nama atribut dengan "/". Misalnya, atribut turunan dari
tipe entitas Staf ditunjukkan pada Gambar 12.11 sebagai / totalStaff .
12.4 Jenis Entitas yang Kuat dan Lemah
Kami dapat mengklasifikasikan tipe entitas sebagai kuat atau lemah.
Jenis entitas kuat Tipe entitas yang tidak bergantung pada keberadaan jenis entitas lain.
Tipe entitas disebut kuat jika keberadaannya tidak bergantung atas keberadaan jenis
entitas lain. Termasuk entitas Staf, Cabang, PropertyForRent, dan Klien. Karakteristik dari
tipe entitas yang kuat adalah bahwa setiap kejadian entitas dapat diidentifikasi secara unik
menggunakan atribut kunci utama dari tipe entitas itu. Misalnya, kita bisa mengidentifikasi
secara unik setiap anggota staf menggunakan atribut staffNo, yang merupakan kunci utama
untuk tipe entitas Staf .
Jenis entitas lemah Tipe entitas yang bergantung pada keberadaan jenis entitas lain.
Tipe entitas yang lemah tergantung pada keberadaan tipe entitas lain. Sebuah contoh tipe
entitas lemah yang disebut Preferensi. Karakteristik dari entitas yang lemah adalah bahwa
setiap kejadian entitas tidak dapat diidentifikasi secara unik hanya menggunakan atribut yang
terkait dengan tipe entitas itu. Sebagai contoh, perhatikan bahwa tidak ada kunci utama untuk
entitas Preferensi. Hal ini berarti bahwa kita tidak dapat mengidentifikasi setiap kemunculan
tipe entitas Preferensi hanya menggunakan atribut kesatuan. Kami dapat secara unik
mengidentifikasi setiap preferensi hanya melalui hubungan preferensi tersebut dengan klien
yang dapat diidentifikasi secara unik menggunakan kunci utama untuk tipe entitas Klien,
yaitu clientNo. Dalam contoh ini, entitas Preferensi digambarkan memiliki ketergantungan
terhadap entitas Klien, yang disebut sebagai entitas pemilik.
Tipe entitas yang lemah kadang-kadang disebut sebagai entitas anak, dependen, atau
entitas bawahan dan tipe entitas yang kuat sebagai induk, pemilik, atau entitas dominan .
12.5 Atribut pada Hubungan
Atribut juga dapat ditetapkan untuk hubungan. Misalnya, pertimbangkan hubungan
Advertises, yang mengaitkan Surat Kabar dan Jenis entitas PropertyForRent. Untuk mencatat
tanggal properti diiklankan dan biayanya, kami mengaitkan informasi ini dengan hubungan
Advertises sebagai atribut yang disebut dateAdvert dan biaya, bukan dengan Surat Kabar atau
Entitas PropertyForRent.
Representasi diagram atribut pada hubungan
Kami mewakili atribut yang terkait dengan jenis hubungan menggunakan simbol yang
sama sebagai tipe entitas. Namun, untuk membedakan antara hubungan dengan atribut dan
entitas, persegi panjang yang mewakili atribut dikaitkan dengan hubungan menggunakan
garis putus-putus. Sebagai contoh, hubungan Advertises dengan atribut dateAdvert dan cost.
Contoh kedua ditunjukkan pada hubungan Manage dengan mgrStartDate dan bonus atribut.
Kehadiran satu atau lebih atribut yang ditetapkan untuk suatu hubungan dapat
menunjukkan bahwa hubungan menyembunyikan tipe entitas yang tidak dikenal. Misalnya,
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
preferensi dari dateAdvert dan atribut biaya pada hubungan Advertises menunjukkan
Kehadiran entitas yang disebut Advert.
12.6 Kendala Struktural
Kami sekarang memeriksa kendala yang mungkin ditempatkan pada jenis entitas yang
berpartisipasi dalam suatu hubungan. Kendala harus mencerminkan pembatasan pada
hubungan seperti yang dirasakan di "dunia nyata." Contoh kendala seperti itu termasuk
persyaratan bahwa properti yang disewakan harus memiliki pemilik dan masing-masing
cabang harus memiliki staf. Jenis utama batasan pada hubungan disebut multiplisitas.
Multiplisitas (Beragam) Jumlah (atau rentang) kemungkinan kejadian dari jenis entitas yang
mungkin terkait dengan kejadian tunggal dari tipe entitas terkait melalui hubungan tertentu.
Multiplicity membatasi cara entitas saling terkait. Hal ini adalah representasi dari
kebijakan (atau aturan bisnis) yang ditetapkan oleh pengguna atau perusahaan. Memastikan
bahwa semua kendala yang tepat diidentifikasi dan diwakili merupakan bagian penting dari
pemodelan suatu perusahaan.
Seperti yang kami sebutkan sebelumnya, derajat paling umum untuk hubungan adalah
biner. Hubungan biner umumnya disebut sebagai satu-ke-satu (1: 1), satu-ke-satu banyak (1:
*), atau banyak-ke-banyak (*: *). Kami memeriksa ketiga jenis hubungan ini menggunakan
batasan integritas berikut:
 seorang anggota staf mengelola cabang (1: 1);
 seorang anggota staf mengawasi properti sewaan (1: *);
 surat kabar mengiklankan properti untuk disewakan (*: *).
Penting untuk dicatat bahwa tidak semua kendala integritas dapat dengan mudah diwakili
dalam model ER. Misalnya, persyaratan seorang anggota staf menerima tambahan hari
liburan untuk setiap tahun kerja dengan perusahaan mungkin sulit untuk diwakili dalam
model ER.
12.6.1 Hubungan Satu-ke-Satu (1: 1)
Pertimbangkan hubungan yang dikelola, yang terkait dengan tipe staf dan cabang.
Gambar 12.14 (a) menampilkan dua kemunculan tipe hubungan Mengelola (dilambangkan rl
dan r2) menggunakan jaring semantik. Setiap hubungan (r n ) mewakili asosiasi antara
kejadian entitas Staf tunggal dan kejadian entitas Cabang tunggal. Kita mewakili setiap
kejadian entitas menggunakan nilai untuk atribut kunci utama dari Staf dan Cabang entitas,
yaitu staffNo dan branchNo .
Menentukan multiplisitas
Menentukan multiplisitas biasanya membutuhkan memeriksa hubungan yang tepat antara
data yang diberikan dalam batasan perusahaan menggunakan data sampel. Contoh data dapat
diperoleh dengan memeriksa formulir atau laporan yang diisi dan, jika mungkin, dari diskusi
dengan pengguna. Namun, penting untuk menekankan bahwa untuk mencapai klusi tentang
persyaratan kendala bahwa data sampel diperiksa atau dibahas representasi sebenarnya dari
semua data yang dimodelkan.
Pada Gambar 12.14 (a) kita melihat bahwa staffNo SG5 mengelola branchNo B003 dan
staffNo SL21 mengelola branchNo BOO5, tapi staffNo SG37 tidak mengelola cabang
manapun. Dengan kata lain, seorang anggota staf dapat mengelola nol atau satu cabang dan
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
masing-masing cabang dikelola oleh satu anggota staf. Karena ada maksimum satu cabang
untuk masing-masing anggota staf yang terlibat dalam hubungan ini dan maksimal satu
anggota staf untuk setiap cabang, kami menyebut jenis hubungan ini sebagai satu-ke-satu,
yang kami biasanya disingkat (1: 1).
Representasi diagram dari hubungan 1: 1
Diagram ER hubungan Staf Mengelola Cabang ditunjukkan pada Gambar 12.14 (b).
Untuk menyatakan bahwa seorang anggota staf dapat mengelola nol atau satu cabang, kami
menempatkan "0..1" di samping entitas Cabang. Untuk menyatakan bahwa cabang selalu
memiliki satu manajer, kami menempatkan "1..1" di samping entitas Staf. (Perhatikan bahwa
untuk hubungan 1: 1, kita dapat pilih nama hubungan yang masuk akal di kedua arah.)
12.6.2 Hubungan Satu-ke-Banyak (1: *)
Pertimbangkan hubungan Oversees, yang menghubungkan jenis entitas Staff dan
PropertyForRent. Gambar 12.15 (a) menampilkan tiga kemunculan tipe hubungan Staf yang
Mengawasi PropertyForRent (dilambangkan rl, r2, dan r3) menggunakan jaring semantik.
Setiap hubungan (r n ) mewakili hubungan antara kejadian entitas Staf tunggal dan terjadi
entitas tunggal PropertyForRent. Kami mewakili setiap kejadian dengan menggunakan nilai
untuk atribut kunci utama entitas Staf dan PropertyForRent, yaitu staffNo dan propertyNo.
Menentukan multiplisitas
Pada Gambar 12.15 (a) kita melihat bahwa staffNo SG37 mengawasi propertyNos PG21
dan PG36, dan staffNo SA9 mengawasi propertyNo PA14 tapi staffNo SG5 tidak mengawasi
setiap prop-Properti untuk disewakan dan properti PG4 tidak ada yang tidak diawasi oleh
anggota staf mana pun. Kesimpulannya, seorang anggota staf dapat mengawasi properti zero
or more untuk disewakan dan properti untuk sewa diawasi oleh zero or one anggota staf.
Karena itu, untuk anggota staf berpartisipasi dalam hubungan ini ada banyak properti untuk
disewakan, dan untuk yang properti yang berpartisipasi dalam hubungan ini ada maksimal
satu anggota staf. Kita lihat tipe hubungan ini sebagai satu-ke-banyak, yang biasanya
disingkat (1: *).
Representasi diagram dari hubungan 1: * Diagram ER Staf
Hubungan PropertyForRent Oversees ditunjukkan pada Gambar 12.15 (b). Untuk
mewakili bahwa seorang anggota staf dapat mengawasi zero or more properti yang
disewakan, kami menempatkan "0 .. *" di samping entitas PropertyForRent. Untuk
menyatakan bahwa setiap properti disewakan diawasi oleh zero or one anggota staf, kami
menempatkan "0..1" di samping entitas Staf. (Perhatikan bahwa dengan hubungan 1: *, kami
memilih nama hubungan yang masuk akal dalam 1: * arah.)
Jika kita tahu nilai minimum dan maksimum aktual untuk multiplisitas, kita bisa
menampilkan ini sebagai gantinya. Misalnya, jika seorang anggota staf mengawasi minimal
nol dan maksimum 100 properti untuk disewa, kita dapat mengganti "0 .. *" dengan "0..100."
12.6.3 Hubungan Many-to-Many (*: *)
Pertimbangkan hubungan Advertises, yang berhubungan dengan jenis entitas Surat Kabar
dan PropertyForRent. Gambar 12.16 (a) menampilkan empat kemunculan hubungan
Advertises (dilambangkan rl, r2, r3, dan r4) menggunakan jaring semantik. Setiap hubungan
(r n ) membenci hubungan antara kejadian entitas Koran tunggal dan terjadinya entitas
tunggal PropertyForRent. Kami mewakili setiap kejadian dengan menggunakan nilai untuk
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
atribut kunci utama entitas Surat Kabar dan PropertyForRent jenis, yaitu newspaperName dan
propertyNo .
Menentukan multiplisitas
Pada Gambar 12.16 (a) kita melihat bahwa Glasgow Daily mengiklankan propertyNos
PG21 dan PG36, The West News juga mengiklankan propertyNo PG36 dan Aberdeen
Express mengiklankan propertyNo PA14. Namun, propertyNo PG4 tidak diiklankan dalam
koran. Dengan kata lain, satu surat kabar mengiklankan satu atau beberapa properti untuk
disewakan dan satu properti untuk disewakan diiklankan di nol atau lebih surat kabar. Karena
itu, untuk surat kabar ada banyak properti untuk disewakan, dan untuk setiap properti
disewakan untuk berpartisipasi dalam hubungan ini ada banyak surat kabar. Kami merujuk
pada jenis hubungan ini sebanyak-ke-banyak, yang biasa disingkat (*: *).
Representasi diagram hubungan *: *
Diagram ER dari Koran Mengiklankan hubungan PropertyForRent ditampilkan di
Gambar 12.16 (b). Untuk menyatakan bahwa setiap surat kabar dapat mengiklankan satu atau
lebih properti untuk disewakan, kami menempatkan "1 .. *" di samping jenis entitas
PropertyForRent. Untuk mewakili bahwa setiap properti yang disewakan dapat diiklankan
oleh nol atau lebih surat kabar, kami menempatkan "0 .. *" di samping entitas Surat Kabar.
(Perhatikan bahwa untuk hubungan *: *, kami dapat memilih nama hubungan yang masuk
akal di kedua arah.)
12.6.4 Multiplisitas untuk Hubungan yang Kompleks
Multiplisitas untuk hubungan yang kompleks—yaitu, yang lebih tinggi dari biner—
sedikit lebih kompleks.
Beragam (hubungan kompleks) Jumlah (atau rentang) kemungkinan kejadian dari jenis
entitas di hubungan n -ary saat nilai-nilai lainnya ( n –1) diperbaiki.
Secara umum, multiplisitas untuk hubungan n -ary mewakili potensi jumlah kemunculan
entitas dalam hubungan ketika ( n –1) nilai ditetapkan untuk jenis entitas yang berpartisipasi
lainnya. Sebagai contoh, banyaknya jenis hubungan terner mewakili kisaran potensi kejadian
entitas entitas tertentu dalam hubungan ketika dua nilai lainnya mewakili dua entitas lainnya
diperbaiki. Pertimbangkan hubungan Register terner antara Staf, Cabang, dan Klien
ditunjukkan pada Gambar 12.7. Gambar 12.17 (a) menampilkan lima kemunculan hubungan
Mendaftar (dilambangkan rl ke r5) menggunakan jaring semantik. Setiap hubungan (r n )
mewakili asosiasi dari kejadian entitas Staf tunggal, Cabang tunggal kejadian entitas, dan
kejadian entitas Klien tunggal. Kami mewakili setiap kejadian entitas menggunakan nilai
untuk atribut kunci utama dari Staf, Cabang, dan Klien entitas, yaitu staffNo, branchNo, dan
clientNo. Pada Gambar 12.17 (a) kami menguji hubungan Register ketika nilai-nilai untuk
Staf dan cabang Cabang telah tetap.
Menentukan multiplisitas
Dalam Gambar 12.17 (a) dengan nilai staffNo / branchNo tetap ada nilai zero or more
clientNo. Misalnya, staffNo SG37 di branchNo B003 register clientNo CR56 dan CR74, dan
staffNo SG14 di branchNo B003 register clientNo CR62, CR84, dan CR91. Namun, SG5 di
branchNo B003 tidak memiliki klien. Dengan kata lain, ketika nilai staffNo dan branchNo
telah tetap sesuai nilai clientNo zero or more. Oleh karena itu, banyaknya hubungan Register
dari perspektif Entitas Staff dan Cabang adalah 0 .. *, yang diwakili dalam diagram ER
dengan menempatkan 0 .. * di samping entitas Klien.
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
Jika kami mengulangi pengujian ini, kami menemukan bahwa multiplisitas ketika nilai
Staf / Klien ditetapkan adalah 1..1, yang ditempatkan di samping entitas Cabang, dan nilai-
nilai Klien / Cabang ditetapkan adalah 1..1, yang ditempatkan di sebelah entitas Staf.
Diagram ER dari hubungan Register terner yang menunjukkan multiplisitas ada pada Gambar
12.17 (b).
Ringkasan cara-cara yang memungkinkan bahwa kendala multiplisitas dapat
direpresentasikan bersama dengan arti deskripsi ditunjukkan pada Tabel 12.1.
12.6.5 Kendala Kardinalitas dan Partisipasi
Multiplisitas sebenarnya terdiri dari dua batasan terpisah yang dikenal sebagai
kardinalitas dan partisipasi.
Kardinalitas Menjelaskan jumlah maksimum dari hubungan yang mungkin terjadi untuk
entitas yang berpartisipasi dalam tipe hubungan tertentu.
CARA ALTERNATIF UNTUK
MEWAKILI BERARTI
CONSTRAIN MUlTIPlICITY
0..1 Nol atau satu kejadian entitas
1..1 (atau hanya 1) Persis satu kejadian entitas
0 .. * (atau hanya *) Nol atau banyak kejadian entitas
1 .. * Satu atau banyak kejadian entitas
5..10 Minimal 5 hingga maksimal 10 kejadian entitas
0, 3, 6–8 Nol atau tiga atau enam, tujuh, atau delapan
kejadian entitas

Kardinalitas dari hubungan biner adalah apa yang sebelumnya kita sebut sebagai satu-
ke-satu (1: 1), satu-ke-banyak (1: *), dan banyak-ke-banyak (*: *). Kardinalitas suatu
hubungan muncul sebagai nilai maksimum untuk rentang multiplisitas di kedua sisi
hubungan. Misalnya, hubungan Mengelola yang ditunjukkan pada Gambar 12.18 memiliki
kardinalitas satu-ke-satu (1: 1), dan ini diwakili oleh rentang multiplisitas dengan nilai
maksimum 1 di kedua sisi hubungan.
Partisipasi Menentukan apakah semua atau hanya beberapa kejadian entitas berpartisipasi
dalam suatu hubungan.
Batasan partisipasi menunjukkan apakah semua kejadian entitas terlibat dalam hubungan
tertentu (disebut sebagai partisipasi wajib) atau hanya beberapa (disebut sebagai partisipasi
opsional). Partisipasi entitas dalam hubungan muncul sebagai nilai minimum untuk rentang
multiplisitas di kedua sisi hubungan. Partisipasi opsional direpresentasikan sebagai nilai
minimum 0, dan partisipasi wajib ditunjukkan sebagai nilai minimum 1. Penting untuk
diperhatikan bahwa partisipasi untuk entitas tertentu dalam suatu hubungan diwakili oleh
nilai minimum pada sisi yang berlawanan dari hubungan; yaitu nilai minimum untuk
multiplisitas di samping entitas terkait. Sebagai contoh, pada Gambar 12.18, partisipasi
opsional untuk entitas Staf dalam hubungan Mengelola ditampilkan sebagai nilai minimum
dari 0 untuk multiplisitas di samping entitas Cabang dan partisipasi wajib untuk entitas
Cabang dalam hubungan Mengelola ditampilkan sebagai nilai minimum 1 untuk multiplisitas
di samping entitas Staf.
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
Ringkasan dari konvensi yang diperkenalkan di bagian ini untuk mewakili konsep
dasar model ER ditampilkan di sampul bagian depan dalam buku ini.
12.7 Masalah dengan Model ER
Di bagian ini kami memeriksa masalah yang mungkin timbul saat membuat model
ER. Masalah-masalah ini disebut sebagai jebakan koneksi, dan biasanya terjadi karena salah
tafsir tentang arti hubungan tertentu (Howe, 1989). Kami memeriksa dua jenis utama jebakan
koneksi, disebut jebakan kipas dan jebakan jurang, dan menggambarkan bagaimana
mengidentifikasi dan menyelesaikan masalah seperti itu dalam model ER.
Secara umum, untuk mengidentifikasi jebakan koneksi, kita harus memastikan bahwa
makna suatu ikatan sepenuhnya dipahami dan didefinisikan dengan jelas. Jika kita tidak
mengerti hubungan kita bisa menciptakan model yang bukan representasi sebenarnya dari
"dunia nyata.”
12.7.1 Perangkap Kipas
Perangkap kipas Di mana model mewakili hubungan antara jenis entitas, tetapi jalur antara
kejadian entitas tertentu bersifat ambigu.
Jebakan kipas mungkin ada di mana dua atau lebih hubungan 1: * keluar dari kesatuan
yang sama. Jebakan kipas potensial diilustrasikan pada Gambar 12.19 (a), yang menunjukkan
dua hubungan 1: * ( Memiliki dan Mengoperasikan ) yang berasal dari entitas yang sama
yang disebut Divisi.
Model ini mewakili fakta bahwa satu divisi beroperasi one or more cabang dan
memiliki satu atau lebih staf. Namun, masalah muncul ketika kita ingin tahu anggota staf
mana yang bekerja di cabang tertentu. Untuk menghargai masalahnya, kami memeriksa
beberapa kemunculan hubungan Has and Operates menggunakan nilai untuk atribut kunci
utama Staf, Divisi, dan jenis entitas cabang, seperti yang ditunjukkan pada Gambar 12.19 (b).
Jika kami mencoba menjawab pertanyaan: “Di cabang mana nomor staf SG37
bekerja?" kami tidak dapat memberikan jawaban spesifik berdasarkan pada struktur saat ini.
Kita hanya dapat menentukan bahwa nomor staf SG37 bekerja di Cabang B003 atau B007.
Ketidakmampuan untuk menjawab pertanyaan ini secara khusus adalah hasil dari jebakan
kipas yang terkait kesalahan penyajian hubungan yang benar antara Staf, Divisi, dan Entitas
cabang. Kami menyelesaikan jebakan kipas ini dengan merestrukturisasi model ER asli untuk
mewakili hubungan yang benar antara entitas-entitas ini, seperti yang ditunjukkan pada
Gambar 12.20 (a).
Jika kita sekarang memeriksa kejadian Operates dan hubungan Has, seperti yang
ditunjukkan pada Gambar 12.20 (b), kita sekarang berada dalam posisi untuk menjawab jenis
pertanyaan yang diajukan.
12.7.2 Jebakan Jurang
Jurang perangkap Dimana suatu model menunjukkan adanya hubungan antar jenis entitas,
tetapi tidak ada jalur antara kejadian entitas tertentu.
Jebakan jurang dapat terjadi di mana ada satu atau lebih hubungan dengan minimum
multiplisitas dari nol (yaitu, partisipasi opsional) membentuk bagian dari jalur antara entitas
terkait. Perangkap jurang potensial diilustrasikan pada Gambar 12.21 (a), yang menunjukkan
hubungan antara entitas Cabang, Staf, dan PropertyForRent.
 RMK SYSTEM MANAJEMEN DATABASE
RESKY ANDRIANI JALIL_A031171336
Model ini mewakili fakta bahwa satu cabang memiliki satu atau lebih staf yang
mengawasi nol atau lebih properti untuk disewakan. Kami juga mencatat bahwa tidak semua
staf mengawasi, dan tidak semua properti diawasi oleh anggota staf. Masalah muncul ketika
kita ingin tahu properti mana yang tersedia di setiap cabang. Untuk menghargai masalah, kita
memeriksa beberapa kejadian dari has dan Mengawasi hubungan menggunakan nilai untuk
atribut kunci utama dari Cabang, Staf, dan PropertyForRent jenis entitas, seperti yang
ditunjukkan pada Gambar 12.21 (b).
Jika kami mencoba menjawab pertanyaan: “Di cabang mana nomor properti PA14
tersedia? " kami tidak dapat menjawab pertanyaan ini, karena properti ini belum dialokasikan
untuk anggota staf yang bekerja di cabang. Ketidakmampuan untuk menjawab ini pertanyaan
dianggap sebagai kehilangan informasi (seperti yang kita tahu properti harus tersedia di
cabang), dan merupakan hasil jebakan jurang. Banyaknya baik entitas Staf dan
PropertyForRent dalam hubungan Oversees memiliki nilai minimum nol, yang berarti bahwa
beberapa properti tidak dapat dikaitkan dengan cabang melalui anggota staf. Karena itu,
untuk mengatasi masalah ini, kita perlu untuk mengidentifikasi hubungan yang hilang, yang
dalam hal ini adalah hubungan Penawaran antara cabang dan entitas PropertyForRent. Model
ER ditunjukkan pada Gambar 12.22 (a) mewakili hubungan sebenarnya antara entitas-entitas
ini. Model ini memastikan bahwa setiap saat, properti yang terkait dengan setiap cabang
diketahui, termasuk properti yang belum dialokasikan untuk anggota staf.
Jika sekarang kita memeriksa kemunculan tipe hubungan Has, Oversees, dan Offers,
seperti yang ditunjukkan pada Gambar 12.22 (b), kami sekarang dapat menentukan nomor
properti itu PA14 tersedia di nomor cabang B007.