ENTITY RELATIONSHIP DIAGRAM

3.1 PENDAHULUAN
Bab ini akan membahas bagaimana profesional sistem menggambarkan model data
secara grafik dengan menggunakan entity relationship diagram yang kadang-kadang
dikenal sebagai ERD (istilah ini yang akan selalu digunakan) atau diagram ER.
Dengan kata lain, ERD adalah suatu model jaringan yang menggunakan susunan
data yang disimpan dalam sistem secara abstrak. Jadi, jelaslah bahwa ERD ini berbeda
dengan DFD yang merupakan suatu model jaringan fungsi yang akan dilaksanakan oleh
sistem , sedangkan ERD merupakan model jaringan data yang menekankan pada struktur-
struktur dan relationship data.
Biasanya ERD ini digunakan oleh profesional sistem untuk berkomunikasi dengan
pemakai eksekutif tingkat tinggi dalam suatu organisasi (seperti: wakil presiden direktur
dan manajer yang tidak tertarik pada pelaksanaan operasi-operasi sistem sehari-hari).
Pemakaian ini lebih tertarik pada data-data apa saja yang dibutuhkan untuk bisnis mereka?
Bagaimana data tersebut berelasi dengan data lainnya? Siapa saja yang diperkenankan
untuk mengakses data tersebut?
ERD juga menguntungkan bagi profesional sistem, karena ERD memperlihatkan
hubungan antara data store pada DFD. Hubungan ini tidak terlihat pada DFD, karena DFD
hanya memusatkan perhatian pada fungsi-fungsi sistem bukan pada data yang dibutuhkan.

3.2 NOTASI ERD

Seperti telah disebutkan diatas bahwa ERD merupakan alat pembuatan model data
secara grafik, maka ERD memiliki notasi-notasi yang digunakan untuk menggambarkan
model data. Notasi-notasi yang digunakan pada bab ini merupakan notasi yang sering
digunakan pada artikel dan buku, seperti pada artikel oleh Chen; buku oleh James Martin,
Elmasri, C.J. Date dan Fred R.Mc Fadden & Jeffrey A.Hoffer.
Notasi-notasi ERD ini dapat dilihat pada Gambar 3.1. Setiap notasi pada ERD
mewakili komponen-komponen ERD yang akan dibahas pada sub berikut.

3.3 KOMPONEN ERD

Komponen utama ERD adalah entitas (entity), relationship dan atribut (attribute).
Masing-masing komponen ini akan dibahas dibawah berikut, sedangkan komponen-
komponen lainnya akan diperkenalkan pada sub bab-sub bab berikutnya.

1 | Entity Relationship Diagram

 DASAR ARTI
Notasi 1 Notasi 2

Entitas

Entitas Lemah

Relationship

Identifying Relationship

Gerund

Atribut

Atribut Kunci Utama

Atribut Multivalue

Atribut Komposisi

Derived Attribute

Derajat Relationship

Unary

Binary

Ternary

Gambar 3.1 Notasi ERD

2 | Entity Relationship Diagram
 DASAR ARTI
Notasi 1 Notasi 2

Kardinalitas Relationship

1 1 Kardinalitas satu-ke-satu

1 M Kardinalitas satu-ke-banyak

M M Kardinalitas banyak-ke-banyak

1:1 Kardinalitas Mandatory One

1:M Kardinalitas Banyak (1,2,….,M)

0:1 Kardinalitas Optional 0 atau 1

0:M Kardinalitas Optional 0 atau

banyak (0,1,2,….,M)

Relationship
Class – Subclass / Subtype – Supertype

ISA
Relationship Class-Subclass
ISA

Relationship Eksklusif

Gambar 3.1 Notasi ERD (Lanjutan)

3 | Entity Relationship Diagram
3.1.1 Entitas
Entitas adalah sesuatu dalam dunia nyata dengan keberadaan yang bebas baik secara
fisik maupun secara abstrak. Entitas dengan keberadaan secara fisik dapat didefinisikan
sebagai orang, benda, tempat. Sedangkan, Entitas dengan keberadaan secara abstrak adalah
kejadian dan konsep. Beberapa contoh dari Entitas diatas adalah :

 Orang : PEGAWAI, MAHASISWA, PASIEN

 Tempat : NEGARA, DAERAH, KOTA
 Benda : KENDARAAN, MESIN, OBAT
 Kejadian: PENJUALAN, PEMBELIAN, PENDAFTARAN
 Konsep : REKENING, KURSUS, MATA KULIAH, PEKERJAAN

Ada perbedaan penting antara tipe entitas dengan instance entitas. Tipe entitas
(kadang-kadang disebut kelas entitas) adalah sekumpulan entitas yang menggunakan sifat
dan karakteristik yang sama. Masing-masing tipe entitas dalam ERD diberikan nama yang
mewakili satu kelas/set dan biasanya menggunakan kata benda. Contoh: MAHASISWA,
KOTA, KURSUS (Lihat Gambar 3.2)

Mahasiswa Kota Kursus

Gambar 3.2 Komponen Tipe Entitas

Instance entitas (intance) adalah satu kejadian tunggal dari tipe entitas. Gambar 3.3
menerangkan perbedaan antara tipe entitas dan dua instancenya. Banyak instance dari tipe
entitas tersebut yang mewakili data yang disimpan dalam database. Misalkan, hanya ada
satu tipe entitas MAHASISWA, tetapi ada banyak instance dari entitas ini yang disimpan
dalam database.
Tipe Entitas : MAHASISWA
Atribut : NPM
NAMA
ALAMAT
RT/RW
KOTA
KODEPOS
T_LAHIR
TGL LAHIR
Instance dari MAHASISWA : 10292432 50293701
Mawarwati Amir Samsudin
Jl. ABC No.13 Jl. BDF No. 35
001/004 012/003
Jakarta Selatan Jakarta Timur
12920 13444
Semarang Jakarta
150673 240274
4 | Entity Relationship Diagram
3.3.2 Atribut
Tiap tipe entitas memiliki sekumpulan atribut yang berkaitan dengannya. Dengan
kata lain, atribut merupakan sifat atau karakteristik suatu entitas yang menyediakan
penjelasan detail tentang entitas tersebut. Bukan hanya entitas yang memiliki atribut, tetapi
relationship.
Dibawah ini, diberikan contoh beberapa tipe entitas beserta atributnya :
 MAHASISWA : NPM, NAMA, ALAMAT, RT/RW, KOTA, KODEPOS
 MOBIL : NO_MOBIL, WARNA, JENIS, CC
 PEGAWAI : NIP, NAMA, ALAMAT, KEAHLIAN

Ada beberapa tipe atribut tersebut yang perlu diperhatikan dalam penggambaran
ERD, yaitu atribut kunci kandidat (candidate key) dan kunci utama (primary key); atribut
bernilai tunggal (single-value attribute) dan bernilai jamak (multivatue attribute); atribut
komposisi (composite attribute) dan atomic (atomic attribute); dan atribut yang dihasilkan
(derived attribute). Kesemua tipe atribut ini akan dijelaskan pada sub bab-sub bab berikut.

3.3.2.1 Atribut kunci kandidat dan kunci utama

Setiap atribut harus memiliki satu atau sekumpulan atribut yang mengidentifikasikan
setiap instancenya secara unik dan membedakan satu instance dengan instance lainnya dari
satu tipe entitas yang sama. Satu atribut atau kombinasi atribut yang mengidentifikasikan
setiap instance suatu entitas secara unik disebut kunci kandidat. Kunci kandidat untuk
MAHASISWA pada contoh diatas adalah NPM.
Beberapa entitas mungkin memiliki lebih dari satu kunci kandidat. Satu kunci
kandidat untuk PEGAWAI adalah NIP; kunci kandidat yang kedua adalah kombinasi dari
NAMA dan ALAMAT (disini diasumsikan bahwa tidak ada dua pegawai dengan nama
yang sama mempunyai alamat yang sama pula). Jika ada lebih dari satu kunci kandidat,
profesional sistem harus memilih salah satu kunci kandidat sebagai kunci utama. Jadi,
kunci utama adalah kunci kandidat yang dipilih sebagai identifier untuk satu tipe entitas.
Ada beberapa kriteria untuk memilih kunci utama, yaitu :
 Pilih kunci kandidat yang tidak akan berubah nilainya selama suatu tipe entitas masih
digunakan dalam database.
 Pilih kunci kandidat yang membuat tiap Instance dari entitas memiliki nilai, jadi
atributnya dijamin memiliki nilai-nilai yang valid dan tidak null.
Gambar 3.4 menunjukkan tampilan untuk tipe entitas MAHASISWA dengan
menggunakan notasi ERD.

Alamat Rt_Rw
Kota
Nama
Kodepos
NPM
Mahasiswa

Gambar 3.4 Entitas dengan Atribut-atributnya

5 | Entity Relationship Diagram
3.3.2.2 Atribut bernilai tunggal dan jamak
Banyak atribut memiliki satu nilai tunggal untuk satu, entitas tertentu, atribut seperti
ini disebut Atribut bernilai tunggal. Misalkan, entitas MAHASISWA memiliki satu nilai
untuk NPM.
Ada juga atribut yang memiliki sekelompok nilai untuk setiap instance entitas,
contohnya atribut WARNA untuk entitas MOBIL. Atribut seperti ini disebut sebagai
Atribut multivalue atau bernilai jamak.
Penggambaran atribut bernilai, tunggal dan jamak dapat dilihat pada Gambar 3.5.

Warna Jenis

Mobil
No.mobil CC

Gambar 3.5 Entitas dengan atribut single value dan multivalue

3.3.2.3 Atribut komposisi dan atomic

Suatu atribut mungkin terdiri dari beberapa atribut yang lebih kecil dengan arti
bebas dari atribut itu sendiri. Atribut ini disebut Atribut komposisi, seperti atribut NAMA
untuk entitas PEGAWAI (Lihat Gambar 3.6)

Nm_Tengah

Nm_Belakang Nm_Depan

Nama

Pegawai

Gambar 3.6 Entitas dengan atribut komposisi

Ada juga suatu atribut yang tidak dapat dibagi kedalam beberapa atribut yang lebih
kecil, atribut ini disebut Atribut atomic, misalkan atribut JENIS untuk entitas MOBIL.

6 | Entity Relationship Diagram

3.3.2.4 Derived Atribut / Atribut yang dihasilkan
Pada beberapa kasus, ada dua atau lebih nilai atribut yang berelasi, misalkan atribut
UMUR dan TGL.LAHIR untuk entitas MAHASISWA. Nilai atribut UMUR dapat
ditentukan dengan tanggal sekarang dan nilai atribut TGL.LAHIR mahasiswa yang
bersangkutan. Atribut UMUR ini disebut Derived attribute dan dikatakan bahwa atribut
UMUR dihasilkan dari atribut TGL.LAHIR. Penggambaran atribut ini dengan
menggunakan notasi ERD dapat dilihat pada Gambar 3.7.

Tgl_lahir Umur

Mahasiswa

Gambar 3.7

3.3.3 Relationship
Relationship merupakan hubungan yang terjadi antara instance-instance dari satu
atau lebih tipe entitas. Misalkan, suatu perguruan tinggi tertarik untuk mengetahui mata
kuliah apa saja yang telah diambil oleh tiap mahasiswanya. Hal ini menuju pada suatu
relationship (yang disebut Mengambil) antara entitas MAHASISWA dan
MATA_KULIAH yang dapat digambarkan sebagai berikut :

Mahasiswa Mata_Kuliah
Mengambil
l

Gambar 3.8 Entitas dengan Relationship Mengambil

Gambar 3.8 diatas menunjukkan relationship banyak-ke-banyak, artinya tiap

mahasiswa mungkin mengambil lebih dari satu mata kuliah, dan tiap mata kuliah mungkin
diambil oleh lebih dari satu mahasiswa. Hal yang lebih penting dari relationship
Mengambil adalah bahwa relationship Mengambil dapat digunakan untuk menentukan
mata kuliah apa saja yang diambil oleh seorang mahasiswa tertentu, sebaliknya dengan
relationship Mengambil mahasiswa-mahasiswa yang telah mengambil mata kuliah tertentu
dapat dicari.
Seperti entitas, relationship juga mungkin memiliki atribut atau sifat yang
membedakannya dengan relationship lainnya. Misalkan, suatu perguruan tinggi ingin

7 | Entity Relationship Diagram

 mencatat semester berapa, seorang mahasiswa mengambil tiap mata kuliah yang
ditawarkan. Jadi Gambar 3.8 diatas dapat diperbaiki seperti pada Gambar 3.9.

Semester

Mahasiswa Mengambil Mata_Kuliah

Gambar 3.9 Relationship Mengambil dengan atribut SEMESTER

Perlu diingat bahwa sebaliknya relationship diberi nama dengan menggunakan frasa
kata kerja yang singkat dan deskriptif pada si pemakai.

3.3.3.1 Derajat Relationship

Derajat Relationship adalah jumlah entitas yang berpartisipasi dalam satu
relationship. Jadi, relationship Mengambil pada contoh diatas adalah relationship berderajat
dua, karena ada dua entitas, yaitu entitas MAHASISWA dan MATA_KULIAH.
Ada tiga derajat relationship yang sering digunakan dalam ERD, yaitu unary
(berderajat satu), binary (berderajat dua) dan ternary (berderajat tiga). Relationship yang
berderajat lebih tinggi mungkin ada saja, tetapi relationship ini jarang, digunakan dalam
praktek, sehingga pembahasan derajat relationship ini hanya dibatasi pada tiga derajat yang
disebutkan diatas. Contoh-contoh relationship unary, binary dan ternary dapat dilihat pada
Gambar 3.10.

Jumlah

Mahasiswa Menikah
Pabrik Mengirimkan Gudang

(a) Relationship Unary

Alat
Pegawai Bekerja Dept
(c) Relationship Ternary
(b) Relationship Binary

Gambar 3.10 Derajat Relationship

Relationship Unary yang sering disebut juga Relationship Rekursif merupakan

relationship antara instance-instance dari satu entitas saja. Pada Gambar 3.10 (a),
relationship Menikahi menunjukkan relationship satu-ke-satu antara instance-instance dari
entitas PEGAWAI.
8 | Entity Relationship Diagram
 Relationship Binary merupakan relationship antara instance-instance dari dua tipe
entitas. Relationship ini yang paling umum digunakan dalam pembuatan model data.
Gambar 3.10 (b) menunjukkan bahwa relationship Bekerja untuk merupakan relationship
banyak-ke-satu, artinya seorang pegawai hanya dapat bekerja untuk satu departemen dan
satu departemen memiliki banyak pegawai.
Relationship Ternary merupakan relationship antara instance-instance dari tiga tipe
entitas secara serentak. Pada Gambar 3.10 (c), relationship Mengirimkan mencatat jumlah
suatu alat tertentu yang dikirimkan oleh suatu pabrik menuju ke suatu gudang yang telah
ditentukan. Masing-masing entitas mungkin berpartisipasi satu atau banyak dalam suatu
relationship ternary.
Perlu dicatat bahwa relationship ternary tidak sama dengan tiga relationship binary.

3.3.3.2 Kardinalitas dalam Relationship

Misalkan ada dua tipe entitas, A dan B, yang dihubungkan dengan satu relationship.
Kardinalitas suatu relationship adalah jumlah instance entitas B yang dapat atau harus
dihubungkan dengan tiap instance entitas A.
Kardinalitas untuk relationship yang umum adalah :
 satu-ke-satu (one-to-one)
 satu-ke-banyak (one-to-many)
 banyak-ke-banyak (many-to-many)
Contoh Kardinalitas dalam relationship adalah pertimbangan relationship berikut
untuk film video :

Film Disimpan sbg

Copy_Film

Gambar 3.11 Contoh Kardinalitas Relationship

Dari contoh diatas jelaslah bahwa suatu toko video mungkin memiliki lebih dari satu
copy untuk film-film tertentu, tetapi toko tersebut mungkin tidak memiliki satu copy pun
dari suatu film tertentu dalam persediaan. Dengan demikian dibutuhkan notasi yang lebih
rinci untuk menunjukkan range kardinalitas untuk suatu relationship.
Kardinalitas minimum dan maksimum. Kardinalitas minimum suatu relationship
adalah jumlah minimum instance dari entitas B yang mungkin berhubungan dengan tiap
instance dari entitas A. Pada contoh sebelumnya, jumlah minimum copy film yang tersedia
untuk suatu film adalah ‘nol’. Kardinalitas maksimum adalah jumlah maksimum instance.
Untuk contoh diatas, jumlah maksimumnya adalah “banyak” (suatu nilai tak terdefinisi
yang lebih dari satu). Dengan menggunakan notasi pada Gambar 3.1, relationship ini
digambarkan sebagai berikut :
Film Disimpan sbg Copy_Film

Gambar 3.12 Contoh Kardinalitas maksimum & minimum

9 | Entity Relationship Diagram
 Pada Gambar 3.12, simbol nol pada garis dekat entitas COPY FILM berarti
kardinalitas minimum nol, sementara notasi berkaki tiga, berarti kardinalitas maksimum
banyak.
Sudah tentu suatu relationship adalah dua Arah (bidirectional), sehingga ada juga
notasi kardinalitas yang dekat entitas FILM. Perhatikan bahwa minimum dan maksimum
entitas ini keduanya sama, yaitu kardinalitas itu. Hal ini disebut Kardinalitas mandatory
one. Dengan kata lain, tiap copy suatu film yang disimpan harus merupakan satu copy tepat
satu film.
Umumnya partisipasi dalam suatu relationship mungkin optimal/parsial atau
mandatory/total untuk entitas yang terlibat. Jika kardinalitas minimum adalah nol, maka
partisipasi adalah optional, sedangkan jika kardinalitas minimum adalah satu, partisipasi
adalah mandatory.
Contoh-contoh dari tiga relationship yang menampilkan semua kombinasi
kardinalitas minimum dan maksimum yang mungkin dapat dilihat pada Gambar 3.13.

Pasien Riwayat
Memiliki
Penyakit

(a) Kardinalitas Mandatory

Pegawai Ditugaskan Proyek

pada

(b) Kardinalitas Satu Optional, Satu Mandatory

Pegawai Menikah
dengan

(c) Kardinalitas Optional

Gambar 3.13 Contoh-contoh Kardinalitas dalam Relationship

10 | Entity Relationship Diagram

Dari Gambar 3.13, ada tiga deskripsi singkat dari masing-masing kardinalitas, yaitu:

 PASIEN Memiliki RIWAYAT PENYAKIT (Gambar 3.13(a)). Setiap pasien memiliki

satu riwayat penyakit atau lebih (diasumsikan bahwa kunjungan awal pasien selalu
dicatat sebagai suatu instance dari RIWAYAT PENYAKIT). Tiap instance RIWAYAT
PENYAKIT dimiliki oleh tepat satu PASIEN (kardinalitas mandatory one yang lain).

 PEGAWAI Ditugaskan pada PROYEK (Gambar 3.13(b)). Tiap PROYEK memiliki

paling sedikit satu PEGAWAI yang ditugaskan pada proyek ini (beberapa proyek
memiliki lebih dari satu pegawai). Tiap PEGAWAI mungkin atau tidak (optional)
ditugaskan pada PROYEK yang ada, atau mungkin ditugaskan pada beberapa PROYEK.

 PEGAWAI Menikahi PEGAWAI (Gambar 3.13(c)). ERD ini adalah kardinalitas nol
atau satu dalam kedua arah, karena seorang pegawai mungkin atau tidak menikah.

Mungkin juga kardinalitas maksimum merupakan jumlah yang sudah pasti, bukan
nilai banyak yang berubah-ubah. Misalkan, kebijakan, perusahaan menyatakan bahwa
seorang pegawai mungkin bekerja pada paling banyak lima proyek pada waktu yang sama.
Dengan aturan ini, angka lima dapat ditempatkan diatas atau dibawah garis berkaki tiga
dekat entitas PROYEK pada Gambar 3.13(b).
Ketergantungan Keberadaan (Existence Dependency). Konsekuensi dari
kardinalitas mandatory one adalah bahwa suatu instance dari tiap entitas tidak akan ada,
kecuali bila ada suatu instance dari tipe entitas yang direlasikan. Misalkan, suatu instance
dari entitas COPY FILM tidak akan ada kecuali entitas.
FILM yang direlasikan sudah ada. Dengan kata lain, ketergantungan keberadaan
berarti bahwa suatu instance dari satu entitas tidak akan ada tanpa keberadaan instance dari
entitas lain yang direlasikannya.
Istilah lain yang sering digunakan untuk tipe entitas yang memiliki kardinalitas
mandatory one adalah entitas lemah (weak entity). Entitas lemah adalah suatu tipe entitas
yang memiliki ketergantungan keberadaan atau suatu entitas yang tidak memiliki atribut
kunci utama. Oleh sebab itu, suatu instance dari entitas lemah tidak akan ada secara bebas,
tetapi tergantung pada keberadaan instance entitas lainnya. Dengan kata lain, beberapa
instance entitas tidak dapat dibedakan satu sama lain, karena kombinasi dan nilai atribut
entitas-entitas tersebut sama. Untuk contoh film video, COPY FILM adalah entitas lemah.
Identifying Relationship. Seperti telah dijelaskan diatas bahwa entitas lemah sering
tidak memiliki identifier alami (atau kunci kandidat), maka kunci utama dari entitas
parent/pemilik (entitas tempat entitas lemah, bergantung) sering digunakan sebagai bagian
kunci utama dari entitas anak (child) yang bergantung. Gambar 3.12 dapat diperbaiki seperti
pada Gambar 3.14.

11 | Entity Relationship Diagram

 No Film Nm Film No Film No Copy

Film Disimpan Sbg Copy_Film

Gambar 3.14 Contoh Entitas Lemah

Pada gambar diatas, tampaklah bahwa kunci utama entitas parent FILM, yaitu
NO_FILM, adalah bagian dari kunci utama entitas anak COPY FILM (NO_COPY adalah
bagian lain dari kunci utamanya). Suatu Identifying relationship merupakan relationship
tempat kunci utama entitas parent digunakan sebagai bagian kunci utama dari entitas anak.
Ada dua keuntungan dari Identifying Relationship, yaitu :
1. Integritas data. Ketergantungan keberadaan dikuatkan karena kunci utama yang dipakai
bersama-sama (oleh sebab itu entitas lemah tidak akan ada kecuali entitas parent ada).
2. Memudahkan pengaksesan entitas anak. Pada contoh diatas, COPY FILM dapat dicari
jika nomor film dan nomor copy diketahui.

3.3.3.3 Gerund
Gerund (yang kadang-kadang disebut entitas komposisi) adalah suatu relationship
banyak-ke-banyak yang menjadi entitas dengan relationship (yang memiliki kardinalitas
satu-ke-banyak, Gambar 3.15 menunjukkan representasi alternatif dari relationship ternary
yang digambarkan pada Gambar 3.10(c). Pada gambar 3.15, tipe entitas (gerund)
PENGIRIMAN menggantikan relationship Mengirim pada Gambar 3.10(c). Simbol belah
ketupat diikut-sertakan dalam simbol persegi panjang untuk entitas sebagai pengingat
bahwa entitas ini, dihasilkan dari suatu relationship.
Tiap instance PENGIRIMAN merepresentasikan pengiriman yang sesungguhnya
dilakukan oleh pabrik alat tertentu menuju ke gudang yang sudah ditentukan. JUMLAH
pengiriman merupakan atribut PENGIRIMAN. Nomor pengiriman, diberikan untuk tiap
pengiriman yang dilaksanakan dan merupakan atribt kunci utama (Lihat Gambar 3.15)

No Pengiriman Jumlah

Pabrik Pengiri Gudang

man

Alat

Gambar 3.15 Tipe Entitas SHIPMENT (Gerund)

12 | Entity Relationship Diagram

 Perlu diingat bahwa notasi belah ketupat tidak digunakan sepanjang, garis dari
gerund ke entitas-entitas lainnya. Hal ini karena garis-garis ini bukan menampilkan
relationship binary. Untuk mempertahankan arti yang sama seperti relationship ternary pada
Gambar 3.10(c), relationship Mengirim dari Gambar 3.10(c) tidak dapat dibagi kedalam tiga
relationship bianry antara PENGIRIMAN dan PABRIK, ALAT dan GUDANG.
Pada relationship binary dengan kardinalitas banyak-ke-banyak, tidak ada salah
apakah relationship ini ditampilkan sebagai gerund atau entitas. Dengan BMS relational,
relationship banyak-ke-banyak baik sebagai gerund ataupun identitas diimplementasikan
dalam cara yang sama, yaitu sebagai tabel database. Untuk relationship ternary atau
berderajat yang lebih tinggi, jika salah satu atau lebih relationship bukan relationship
banyak, maka relationship ini tidak dapat ditampilkan sebagai entitas.

3.4 PEMBUATAN MODEL ATRIBUT MULTIVALUE

Pada pembahasan atribut sebelumnya, WARNA digunakan sebagai contoh atribut
multivalue. Penggambaran atribut ini menggunakan elips bergaris ganda (Lihat Gambar
3.16(a)). Biasanya atribut-atribut multivalue sering dihapus dari entitasnya, kemudian
dibentuk entitas baru yang memiliki relationship dengan entitas tempat atribut multivalue
dihapus.
Pada Gambar 3.16(b), tipe entitas baru WARNA menggantikan atribut WARNA.
Sekarang ada relationship banyak-ke-banyak antara MOBIL dari WARNA, JENIS
WARNA dipilih sebagai kunci utama WARNA. Secara tipikal, untuk menjadi entitas
disamping memiliki kunci utama (yaitu JENIS WARNA) WARNA harus juga memiliki
beberapa atribut bukan kunci.
Kelompok Data Berulang. Kelompok Data Berulang merupakan sekumpulan atau
lebih atribut multivalue yang secara logika bervariasi. Contoh, Gambar 3.17(a) merupakan
form kartu pasien yang menunjukkan data bagi pasien dan pasien tersebut berkunjung ke
suatu klinik. Gambar 3.17(b) merupakan ERD awal dari tipe entitas PASIEN dengan tiga
atribut multivalue untuk tiap pasien, yaitu TGL KUNJUNG, DOKTER dan GEJALA.
Ketiga atribut ini secara logika direlasikan dan membentuk kelompok berulang (disini
diasumsikan bahwa hanya ada satu kunjungan pada tanggal tertentu dan bahwa pasien
hanya menemui seorang dan diperiksa untuk satu gejala tiap berkunjung).

Warna Jenis

No Mobil CC
Mobil

(a) Entitas dengan Atribut Multivalue

13 | Entity Relationship Diagram

 No Mobil Jenis CC JenisWarna

Mobil Warna
Memiliki

(b) Atribut Multivalue Dihapus

Gambar 3.16 Penghapusan Atribut Multivalue dari Entitas

Gambar 3.17(c) menunjukkan hasil penghapusan kelompok berulang dari PASIEN.

Tipe entitas baru yang disebut RIWAYAT PASIEN dibentuk, dan tiga atribut multivalue
yang membentuk kelompok berulang dipindahkan dari entitas PASIEN. TGL KUNJUNG
dipilih sebagai kunci utama tipe entitas baru ini. Ada relationship satu-ke-banyak dari
PASIEN dan RIWAYAT PASIEN, dan RIWAYAT PASIEN adalah entitas lemah.

3.5 PEMBUATAN MODEL DATA TERGANTUNG PADA WAKTU

Isi database berubah dari waktu ke waktu. Misalkan, dalam database yang berisi:
Informasi produk, harga untuk tiap produk mungkin berubah bila biaya bahan, upah kerja
dan kondisi pasar berubah. Jika hanya harga saat ini dibutuhkan, maka hanya nilai harga ini
yang perlu ditampilkan.
Gambar 3.18(a) menunjukkan hal ini sebagai serangkaian harga dan tanggal
berlakunya tiap harga tersebut. Hal ini menghasilkan kelompok data berulang yang
memasukkan atribut-atribut HARGA dan TGL BERLAKU. Pada Gambar 3.18(b),
kelompok berulang ini diganti dengan entitas baru, (entitas lemah) yang diberi nama
RIWAYAT HARGA. Relationship antara PRODUK dan RIWAYAT HARGA adalah
Memiliki.

14 | Entity Relationship Diagram

 Kartu Pasien
No. Pasien : A0014
Nama Pasien : Amelia Indah
Alamat : Jl. XYZ

Tgl.
Kunjungan Dokter Gejala
03-02-95 Amir Demam
17-06-95 Hasan Sakit Tenggorokan
16-08-95 Amir Flu
……
……
……

(a) Contoh Data

Nama Pasien
No Pasien Alamat

Pasien

Tgl Kunjungan
Tgl Kunjungan2
Tgl Kunjungan1

(b) Entitas dengan Kelompok Berulang

No Pasien Nama Pasien

Alamat Tgl Kunjungan

Dokter

Pasien Memiliki
Riwayat
Pasien
Gejala

No Pasien

(c) Kelompok Berulang Dihapus

Gambar 3.17 Penghapusan Kelompok Berulang

15 | Entity Relationship Diagram

16 | Entity Relationship Diagram