IF162615 PERANCANGAN BASIS DATA

Konsep Entitas & Relasi

Anggoro Ari Nurcahyo ST., M.Kom

Representasi Diagram
Ta t a c a r a m e n g g a m b a r d i E R - D d a n o v e r v i e w
Simbol Dasar
Penggunaan simbol yang digunakan dalam ER

Kami mulai dengan menyajikan model kami sebagai diagram struktur data hanya
menggunakan dua simbol:

1 Sebuah "kotak" (tepatnya, persegi panjang) mewakili sebuah entitas/ tabel.

2
Panah yang ditarik di antara dua kotak mewakili foreign key yang menunjuk kembali ke tabel di mana ia
muncul sebagai primary key. Dalam notasi representasinya menggunakan belah ketupat dan garis di
antaranya.

IF162615 | PERANCANGAN BASIS DATA 3

Simbol Dasar
Penggunaan simbol yang digunakan dalam ER

Entitas
Simbol untuk entitas, gambar disamping terdapat 7 entitas
dalam kasus rumah sakit dalam kegiatan operasi.

IF162615 | PERANCANGAN BASIS DATA 4

Representasi Diagram Foreign Key
Penggunaan simbol yang digunakan dalam ER

Contoh Relasi dan pembuatan foreign key

Untuk memahami cara menggambar relasi/garis/panah, lihat
entias operation dan Surgeon. Primary Key Surgeon (Hospital
Number + Surgeon Number) muncul di tabel operation
sebagai Foreign Key. Buat relasi di antara dua kotak, dan
tunjukkan arah tautan dengan meletakkan “Crow foot" di
ujung Foreign key. Anda dapat menganggap operation
sebagai panah yang menunjuk kembali ke Surgeon yang
relevan untuk setiap operasi.

IF162615 | PERANCANGAN BASIS DATA 5

Interpreting the Diagram
Jika disajikan hanya dengan diagram Sebelumnya, kami dapat menyimpulkan setidaknya empat hal penting:

1 Model menentukan tabel Surgeon (karena itu kami ingin menyimpan data tentang ahli bedah).

2 Model menetapkan tabel Operation (karena itu kami ingin menyimpan data tentang operasi).

3
Setiap operasi dapat dikaitkan dengan hanya satu Surgeon (karena kunci dari Ahli Bedah hanya dapat
muncul sekali di setiap baris tabel Operation, dan ini tercermin dalam diagram dengan crow
foot“menunjuk kembali” ke satu baris Surgeon).

4
Setiap Surgeon dapat dikaitkan dengan banyak operasi (karena tidak ada yang dapat menghentikan
banyak baris tabel Operation yang berisi nilai yang sama untuk Foreign Key dari Ahli Bedah; sekali lagi,
posisi kaki gagak pada akhir Operation dari panah menangkap ini) .

The Power of PowerPoint | thepopp.com 6

Interpreting the Diagram
Penafsiran diagram

Dua aturan pertama akan terlihat jelas dari representasi relasional. Sekarang kami dapat bertanya kepada seorang
spesialis bisnis, dengan mengacu pada diagram: "Apakah benar setiap operasi dilakukan oleh satu ahli bedah
saja?" Mungkin saja tidak demikian, atau tidak dapat diandalkan di masa depan. Untungnya, kami telah
mengidentifikasi masalah sementara biaya perubahan masih hanya sedikit waktu pengerjaan ulang model. Mari
kita asumsikan bahwa klien sebenarnya menegaskan bahwa hanya satu ahli bedah yang harus dicatat untuk setiap
operasi tetapi menawarkan beberapa penjelasan: sementara lebih dari satu ahli bedah pada kenyataannya dapat
berpartisipasi dalam suatu operasi, klien hanya tertarik untuk mencatat rincian ahli bedah yang mengatur operasi.
Pertama untuk menghindari pertanyaan ditinjau kembali, dan kedua untuk menentukan dengan lebih tepat data apa
yang akan disimpan. Sekarang jelas bahwa database tidak akan dapat menjawab pertanyaan: "Dalam berapa
banyak operasi yang dilakukan oleh ahli bedah nomor 12 di rumah sakit nomor 18?" Ini akan mendukung: "Berapa
banyak operasi yang dikelola oleh ahli bedah nomor 12 di rumah sakit nomor 18?" Selain memberi anotasi pada
diagram, kita harus mengubah nama kolom Surgeon Number di tabel Operasi menjadi "Managing Surgeon
Number."
IF162615 | PERANCANGAN BASIS DATA 7
Optionality
Istilah lain yang sering digunakan untuk entitas yang digunakan bersifat opsional atau Wajib (mandatory)

Diagram juga dapat meningkatkan kemungkinan operasi yang tidak melibatkan ahli bedah sama sekali: “Kami
biasanya tidak melibatkan ahli bedah saat merawat pasien dengan luka kecil, tetapi kami masih perlu mencatat
apakah ada obat yang digunakan. ” Dalam kasus ini, beberapa baris dalam tabel Operasi mungkin tidak berisi nilai
untuk Surgeon Number. Kami dapat menunjukkan apakah keterlibatan seorang ahli bedah dalam suatu operasi
adalah opsional atau wajib dengan menggunakan konvensi Gambar disamping. Perhatikan bahwa komentar
tentang opsionalitas biasanya tidak ditampilkan pada diagram seperti itu. Anda dapat menganggap lingkaran
sebagai nol dan batang tegak lurus sebagai satu, menunjukkan jumlah minimum ahli bedah per operasi atau (di
ujung panah) operasi per ahli bedah.
IF162615 | PERANCANGAN BASIS DATA 8
Optionality
Istilah lain yang sering digunakan untuk kardinalitas atau isitlah lainnya mandatory

Diagram kami sekarang berisi informasi

tentang tabel Bedah dan Operasi serta
keterkaitannya sebanyak yang dapat dicatat
tanpa benar-benar mencantumkan kolom. Hasil
penerapan aturan untuk seluruh model
pengeluaran obat ditunjukkan pada Gambar
berikut.

IF162615 | PERANCANGAN BASIS DATA 9

Relationships
Menghubungkan 2 entitas yang saling berkaitan.
Konvensi Pembuatan Diagram Hubungan
Penggunaan simbol yang digunakan dalam ER

Konvensi Pembuatan Diagram Hubungan

Kami telah menggunakan konvensi untuk menganotasi garis
untuk mendeskripsikan artinya (nama hubungan), kardinalitas
(Crow foot dapat diartikan sebagai "banyak," ketiadaannya
berarti "satu"), dan opsionalitas (lingkaran dan batang yang
mewakili "Opsional" dan "wajib" masing-masing).
Perhatikan bahwa kami telah menamai hubungan di kedua
arah: "issue" dan "diterbitkan oleh". Ini memungkinkan kami
untuk menafsirkan hubungan dengan cara yang sangat
terstruktur dan formal:
"Setiap perusahaan dapat menerbitkan satu atau lebih saham."
dan
"Setiap saham harus diterbitkan oleh satu perusahaan."

IF162615 | PERANCANGAN BASIS DATA 11

Konvensi Pembuatan Diagram Hubungan
Agar dapat secara otomatis menerjemahkan hubungan menjadi pernyataan tentang data bisnis, beberapa aturan perlu dibuat:

Kami harus memilih nama hubungan yang sesuai dengan struktur kalimat. Ada baiknya mencoba

1 menggunakan kata kerja yang sama di kedua arah ("hold(tahan)" dan "be held by (dipegang oleh)," atau
"bertanggung jawab untuk" dan "menjadi tanggung jawab") untuk memastikan bahwa hubungan tersebut
tidak ditafsirkan sebagai membawa dua arti yang terpisah .

Kita harus memberi nama hubungan di kedua arah, meskipun ini menambah sedikit artinya. Kami

2 mempraktikkan tidak hanya menempatkan setiap nama relasi dekat dengan entitas yang merupakan objek
kalimat, tetapi juga menyusun nama di atas dan di bawah garis sehingga dibaca searah jarum jam saat
membuat kalimat (seperti, misalnya, pada Gambar slide 11).

3 Kita harus tegas dalam menggunakan nama tunggal untuk entitas. Seperti disebutkan sebelumnya, disiplin
ini layak diikuti apa pun konvensi penamaan hubungan.

IF162615 | PERANCANGAN BASIS DATA 12

Relasi
menunjukkan beberapa relasi/hubungan yang biasa kita temui dalam praktik

1
Crow Foot mungkin muncul di salah satu, atau kedua ujung relasi (many-to-many) . Ketiga alternatif
tersebut masing-masing disebut sebagai hubungan one-to-one, one-to-many, and many-to-one
relationships.

2 Mungkin ada lebih dari satu hubungan antara dua kelas entitas yang sama.

3 Entitas yang sama dapat muncul di kedua ujung hubungan. Ini disebut hubungan "mengacu pada diri
sendiri" atau "rekursif".

IF162615 | PERANCANGAN BASIS DATA 13

Relasi
menunjukkan beberapa relasi/hubungan yang biasa kita temui dalam praktik

one-to-one
Setiap Departemen harus dikelola oleh satu Manajer. Setiap
Manajer dapat mengelola satu Departemen.

one-to-many
Setiap Departemen mungkin bertanggung jawab atas satu atau
lebih Proyek. Setiap Proyek harus menjadi tanggung jawab
satu Departemen.

many-to-many
Setiap Karyawan dapat diberikan satu atau lebih Kualifikasi.
Setiap Kualifikasi dapat diberikan kepada satu atau lebih
Karyawan.

IF162615 | PERANCANGAN BASIS DATA 14

Relasi
menunjukkan beberapa relasi/hubungan yang biasa kita temui dalam praktik

two relationships
Setiap Karyawan harus memegang satu Posisi. Setiap Posisi
dapat dipegang oleh satu Karyawan.
dan
Setiap Karyawan dapat bertindak dalam satu atau lebih Posisi.
Setiap Posisi dapat ditindaklanjuti oleh satu Karyawan.

self-referencing one-to-many
Setiap Bidang Tanah dapat mencakup satu atau lebih Bidang
Tanah.
Setiap Bidang Tanah dapat dimasukkan dalam satu Bidang
Tanah.

IF162615 | PERANCANGAN BASIS DATA 15

Relasi
menunjukkan beberapa relasi/hubungan yang biasa kita temui dalam praktik

self-referencing many-to-many
Setiap Bagian yang Diproduksi mungkin merupakan rakitan
dari satu atau lebih Bagian yang Diproduksi.
Setiap Bagian yang Diproduksi mungkin merupakan
komponen dari satu atau lebih Bagian yang Diproduksi.

IF162615 | PERANCANGAN BASIS DATA 16

Many-to-Many Relationships
Hubungan banyak-ke-banyak muncul secara teratur dalam diagram ER dalam praktiknya dan hanya di layer lojik

Hubungan banyak-ke-banyak muncul secara teratur dalam

diagram ER dalam praktiknya. Tetapi jika Anda melihat
kembali diagram pengeluaran obat pada Gambar slide 8,
Anda akan melihat bahwa diagram tersebut hanya berisi
hubungan satu-ke-banyak. Ini bukan kebetulan, tetapi
merupakan konsekuensi dari prosedur yang kami gunakan
untuk menggambar diagram dari tabel yang dinormalisasi.
Ingatlah bahwa setiap nilai foreign Key menunjuk ke satu
baris (mewakili satu contoh entitas), dan setiap nilai dapat
muncul berkali-kali; karenanya, kita hanya bisa berakhir
dengan hubungan satu-ke-banyak saat mendokumentasikan
sekumpulan tabel relasional.

IF162615 | PERANCANGAN BASIS DATA 17

Many-to-Many Relationships
Hubungan banyak-ke-banyak muncul secara teratur dalam diagram ER dalam praktiknya dan hanya di layer lojik

Bagaimana kita mengimplementasikan hubungan menggunakan foreign Key? Jawabannya adalah bahwa kami
tidak dapat menggunakan DBMS relasional standar. Kami tidak dapat memegang kunci(Primary Key)
Kualifikasi dalam tabel Karyawan karena seorang karyawan dapat memiliki beberapa kualifikasi. Hal yang
sama berlaku untuk tabel Kualifikasi, yang perlu mencatat banyak karyawan. Model yang dinormalisasi tidak
dapat mewakili hubungan banyak-ke-banyak dengan foreign Key, namun hubungan seperti itu pasti ada di
dunia nyata. Pratinjau singkat dari jawabannya: meskipun kita tidak dapat mengimplementasikan hubungan
banyak-ke-banyak dengan foreign Key, kita dapat mengimplementasikannya dengan entitas bentukan (anda bisa
menggunakan pendekatan normalisasi dalam melakukannya, akan dibahas di pertemuan-pertemuan berikutnya).

IF162615 | PERANCANGAN BASIS DATA 18

Many-to-Many Relationships
Hubungan banyak-ke-banyak muncul secara teratur dalam diagram ER dalam praktiknya dan hanya di layer lojik

Penamaan tabel menghadirkan sedikit tantangan. Karyawan dan Kualifikasi cukup jelas, tapi bagaimana dengan
tabel lainnya? Hubungan Kualifikasi Karyawan adalah salah satu opsi dan masuk akal karena tabel yang kurang
jelas ini mewakili hubungan banyak-ke-banyak antara dua lainnya. Hasilnya ditunjukkan secara diagram pada
Gambar diatas
Contoh ini menggambarkan aturan umum yang penting. Setiap kali kita menemukan hubungan banyak-ke-
banyak antara dua kelas entitas, kita dapat menerapkannya dengan memperkenalkan tabel ketiga selain tabel
yang diturunkan dari dua kelas entitas asli. Tabel ketiga ini disebut dengan berbagai cara sebagai tabel
perpotongan, enitas/tabel hubungan, asosiatif, atau resolusi. Kami menyebut proses ini "menyelesaikan
hubungan banyak-ke-banyak." Tidak perlu melalui proses normalisasi setiap saat; kami hanya mengenali
polanya dan menanganinya dengan cara standar.
IF162615 | PERANCANGAN BASIS DATA 19
Many-to-Many Relationships
Hubungan banyak-ke-banyak muncul secara teratur dalam diagram ER dalam praktiknya dan hanya di layer lojik

Perhatikan sifat opsional / wajib dari hubungan baru dan bagaimana mereka berasal dari sifat
opsional / wajib dari hubungan banyak ke banyak asli:

1
Ujung "satu" dari hubungan baru akan selalu bersifat wajib (karena contoh hubungan tanpa kedua kelas
entitas asli yang berpartisipasi — dalam hal ini, hubungan kualifikasi karyawan tanpa karyawan dan
kualifikasi — tidak masuk akal) .

2 Ujung "banyak" dari hubungan baru akan bersifat opsional atau wajib bergantung pada ujung yang sesuai
dari hubungan asli.

IF162615 | PERANCANGAN BASIS DATA 20

One-to-One Relationships
Hubungan one-to-one jauh lebih jarang daripada hubungan lainnya.

Reaksi pertama Anda terhadap hubungan satu-ke-satu harus memverifikasi bahwa Anda telah melakukannya
dengan benar.
Hubungan satu-ke-satu dapat menjadi alat yang berguna untuk mengeksplorasi cara alternatif pemodelan
situasi, memungkinkan kita untuk "memecah" entitas tradisional dan menyusunnya kembali dengan cara baru.
Mereka juga menghadirkan beberapa masalah khusus dalam implementasi. Secara khusus, perhatikan bahwa
Anda tidak boleh secara otomatis menggabungkan entitas yang ditautkan oleh relasi ini.

IF162615 | PERANCANGAN BASIS DATA 21

Self-Referencing Relationships
untuk menggambarkan hubungan memiliki entitas yang sama di kedua ujungnya.

Jenis hubungan ini kadang-kadang disebut " head scratcher", bukan hanya karena penampilannya, tetapi karena
kesulitan yang dihadapi banyak orang untuk memahami struktur rekursif yang diwakilinya. Kami menafsirkan
ini dengan cara yang sama seperti hubungan lainnya, kecuali bahwa kedua orang dalam hubungan tersebut
adalah entitas yang sama:

"Setiap Karyawan dapat mengelola satu atau lebih Karyawan."

dan
"Setiap Karyawan dapat dikelola oleh satu Karyawan.“

Model tersebut merepresentasikan hierarki karyawan yang sederhana seperti yang mungkin ditampilkan pada
bagan organisasi. Untuk mengimplementasikan hubungan menggunakan kunci asing, kita perlu membawa
kunci Karyawan (katakanlah, ID Karyawan) sebagai kunci asing di tabel Karyawan.
IF162615 | PERANCANGAN BASIS DATA 22
Self-Referencing Relationships
untuk menggambarkan hubungan memiliki entitas yang sama di kedua ujungnya.

Hubungan ini, karena banyak-ke-banyak, tidak dapat diimplementasikan oleh satu tabel dengan kunci asing
yang sesuai. Namun, kita dapat menyelesaikannya dengan cara yang sama seperti hubungan banyak-ke-banyak
antara dua kelas entitas yang berbeda.

Dalam menangani hal tersebut, kami untuk sementara membagi Manufactured Part dibagi menjadi dua,
memberi kami hubungan banyak-ke-banyak kepada dua entitas yang sudah dibuat, dan menyelesaikannya
dengan penjelasan sebelumnya di pembahasan banyak-ke-banyak (membuat entitas asosiatif). Kami kemudian
menggabungkan kembali dua bagian dari tabel terpisah, berhati-hati agar tidak kehilangan hubungan apa pun.

IF162615 | PERANCANGAN BASIS DATA 23

Self-Referencing Relationships
untuk menggambarkan hubungan memiliki entitas yang sama di kedua ujungnya.

Struktur yang ditunjukkan pada gambar(d) dapat digunakan untuk

merepresentasikan hubungan banyak-ke-banyak yang mengacu pada diri
sendiri (Self-Referencing). Ini sering disebut sebagai struktur Bill of
Material, karena dalam manufaktur, bill of material mencantumkan
semua komponen tingkat terendah yang diperlukan untuk membangun
produk tertentu dengan secara bertahap memecah rakitan, subassemblies,
dan sebagainya. Perhatikan bahwa tabel Manufactured Part Usage
menyimpan dua kunci asing yang menunjuk ke Manufactured Part
(Assembly Manufactured Part Number dan Component Manufactured
Part Number) untuk mendukung dua hubungan. Hubungan referensi
mandiri adalah bagian penting dari kit alat pemodel data dan muncul di
sebagian besar model data. Mereka digunakan untuk mewakili tiga jenis
struktur: hierarki, jaringan, dan rantai (lebih jarang).

IF162615 | PERANCANGAN BASIS DATA 24

Dependent and Independent Entity
Jenis entitas yang bisa digunakan istilah lainnya strong dan weak entity

entitas independen adalah entitas yang instansinya dapat memiliki keberadaan independen. Sebaliknya,
entitas dependen adalah yang instansinya hanya dapat ada dalam hubungannya dengan instans entitas lain,
dan tidak dapat ditransfer antara instans dari entitas lain tersebut. Dengan kata lain, entitas bergantung jika
(dan hanya jika) memiliki hubungan wajib, banyak-ke-satu (atau satu-ke-satu) dengan kelas entitas lain.
Misalnya, kami berharap Order Item (item pesanan) menjadi entitas yang dependen: item pesanan tidak
dapat berada di luar order dan tidak dapat ditransfer antar pesanan.
entitas dependen dapat membentuk hierarki beberapa level, serta bergantung pada lebih dari satu entitas
pemilik.

IF162615 | PERANCANGAN BASIS DATA 25

Relationship Names
Beberapa kata di salah satu area yang paling sering diabaikan dalam pemodelan — penamaan hubungan.

Model ER harus selalu dianotasi dengan benar dengan nama hubungan yang bermakna (tidak "terkait dengan"
atau "terkait dengan"). Pengecualian aturan ini adalah dua hubungan yang muncul dari penyelesaian hubungan
banyak ke banyak, karena nama hubungan biasanya digunakan untuk memberi nama kelas entitas baru. Kami
menyarankan "melibatkan (Involve)" dan "terlibat dalam (be involved in)" sebagai nama yang bisa diterapkan,
seperti pada Gambar slide 19, tetapi hanya untuk hubungan yang muncul dari penyelesaian hubungan banyak-
ke-banyak.
Contoh yang baik dari kebutuhan akan nama yang bermakna adalah hubungan antara Country (negara) dan
Currency (Mata Uang), seperti yang mungkin diperlukan dalam database untuk mendukung transaksi mata
uang asing. Gambar diatas menunjukkan dua kelas entitas. Apa hubungan antara kedua kelas entitas ini? Satu-
ke-banyak? Banyak ke banyak? Kami tidak dapat menjawab pertanyaan-pertanyaan ini sampai arti dari
hubungan tersebut telah diklarifikasi.
IF162615 | PERANCANGAN BASIS DATA 26
Relationship Names
Beberapa kata di salah satu area yang paling sering diabaikan dalam pemodelan — penamaan hubungan.

Apakah kita berbicara tentang fakta bahwa mata uang dikeluarkan oleh suatu negara, apakah legal tender di
negara tersebut, atau dapat diperdagangkan di negara tersebut? Hasil dari penyelidikan kami mungkin adalah
kami mengidentifikasi lebih dari satu hubungan antara pasangan kelas entitas yang sama. Ada masalah yang
lebih mendasar di sini yang dapat mempengaruhi kardinalitas. Apa yang kami maksud dengan "negara"? Sekali
lagi, sebuah kata bisa memiliki banyak arti. Apakah Tahta Suci (Kota Vatikan) memenuhi syarat sebagai
negara? Jika hubungan "dikeluarkan oleh", apakah kami mendefinisikan Euro sebagai diterbitkan oleh beberapa
negara, atau apakah kami merevisi definisi (dan nama) entitas Negara untuk mengakomodasi "Uni Eropa,"
sehingga menjaga hubungan sebagai satu-ke -banyak? Intinya adalah bahwa definisi hubungan terkait erat
dengan definisi entitas yang berpartisipasi. Kami fokus pada definisi kelas entitas terlebih dahulu, tetapi analisis
kami tentang hubungan dapat mengarahkan kami untuk merevisi definisi ini.

IF162615 | PERANCANGAN BASIS DATA 27

Relationship Names
Beberapa kata di salah satu area yang paling sering diabaikan dalam pemodelan — penamaan hubungan.

Contoh dari tipe kelas entitas lain yang dapat menyebabkan masalah definisi adalah kelas entitas Position
(Posisi) dalam model Sumber Daya Manusia (HRD). Apakah posisi merupakan istilah umum seperti
"Administrator Basis Data," yang mungkin ada lebih dari satu di organisasi, atau posisi yang dianggarkan
khusus dengan suatu penghuni? Atau posisi dari seorang pegawai? Kita perlu tahu sebelum kita dapat
menggambar hubungan kelas entitas Posisi dengan benar.

IF162615 | PERANCANGAN BASIS DATA 28