ENTITY RELATIONSHIP DIAGRAM

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.

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 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
 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
 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
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
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.

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
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

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
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

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
 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.

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
 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.

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
 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
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
 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.

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
 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.

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
 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.

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.

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

14
 (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

NORMALISASI
Dalam merancang data base arus dapat di jawab apabila kita di berikan data,maka
bagaimana kita menentukan struktur logik yang tepat untuk data tersebut, atau bagaimana
kita menentukan rellation-relation yang di perlukan dan apa atributnya.
Semua relation dan relational data baseselalu sudah ternormalisasi, dalam arti bahwa
semua relation sudah di definisikan terhadap domain sederhana, yaitu domain yang hanya
berisi nilai atomik. Dalam normalisasi lanjutan kita berusaha untuk
menghilangkan/mengurangi data yang di duplikasi atau mubazir agar supaya mendapatkan
bentuk yang baik,hemat tempat, hemat waktu, hemat biaya dan menberikan respon yang
baik dan cepat.

15
 Metode normalisasi adala suatu pproses perancangan data base untuk mendapatkan
bentuk normal. Normalisasi berkaitan dengan suatu proses sedang Normal From berkaitan
dengan output proses. Jika suatu relasi berada dalam bentuk normal, maka ia juga termasuk
dalam bentuk normal tersebut di dalamnya/di bawahnya. Contoh : jika suatu berada dalam
bentuk 2NF, maka relasi tersebut termasuk pula dalam bentuk 1NF.

1NF
2NF
3NF
BCNF
4NF
5NF

Suatu relation dikatakan sudah berada pada bentuk normalisasi tertentu bila
memenuhi beberapa batasan tertentu pada tingkat tersebut. Tingkat normalisasi yang lebih
tinggi di anggap lebih baik dari tingkat dibawahnya.

Tingkat-tingkat normalisasi :
1. Relation umum (yang belum dan yang sudah ternormalisasi)
2. 1NF (First Normal Form) relation yang sudah ternormalisasi.
3. 2NF (Secound Normal Form) relation.
4. 3NF (Third Normal Form) relation.
5. BCNF (Boyce Codd Normal Form) relation.
6. 4NF (Fourth Normal Form) relation.
7. PJ/NF(Project Join Normal Form) atau 5NF(Fifth Normal Form) relation

Aplikasi yang dapt diselesaikan hanya sampai bentuk normal 3. Aplikasi Normal Form
BCNF – DKNF cenderung menggunakan aplikasi matematika yang lebih rumit di
bandingkan dengan bentuk aplikasi 1NF – 3NF. Bentuk DKNF sampai sekarang masih
sebagai hipotesa belum di buktikan. Untuk 6NF dan 7NF dan seterusnya belum terpikirkan
saat ini.
Dalam Unnormalized Relation masih banyak ditemui bentuk normal seperti tabel yang
telahh dicatat di atas yang menpunyai ciri berulang (data redudant) dalam suatu grup.

16
LANGKAH - LANGKAH NORMALISASI

UNNORMALIZED
RELATION

Menghilangkan ciri yang berulang

1 NF

Menghilangkan ketergantungan partial

2 NF

Menghilangkan ketergantungan transitil

3 NF

FUNCTIONALLY DEPENDENT DAN FUNCTIONALLY DETERMINES

Suatu atribut Y di sebut functionally dependent tarhadap atribut X dalam suatu

relation R bila setiap nilai X di R hanya ada satu hubungan ketergantungan dengan nilai Y
di R pada suatu saat. Ditulis R.X R.Y

Contoh dalam database suplier dan part, atribut SNAME,STATUS dan CITY dari
relation S semua tergantung pada (functionally dependent) terhadap atribut S# karena setiap
nilai S# hanya ada satu hubungan dengan nilai-nilai di SNAME, STATUS dan CITY.

Dalam simbol dapat kita tulis sebagai :

S.S# → S. SNAME
S.S# → S.STATUS
S.S# → S.SCITY
Atau S.S → S.(SNAME,STATUS,CITY)
S.S# → S.SNAME menyatakan S.SNAME functionally dependent terhadap S.S# Atau
sebaliknya S.S# functionally determines S.SNAME

Functionally dependent (FD) adalah salah sat dari batasan integritas (Integrity
Constraints).
PNAME
SNAM
COLOR
EE S#
S# STATU P
WEIGHT QT
S # P#
CITY Y
CITY

Gambar 1. Functional Dependent di relasion S,P, dan SP

17
FIRST NORMAL FORM (1NF)
SP1 SP2
S# PQ S# P# QTY
P# QTY S1 P1 300
S1 P1 300 S1 P2 200
P2 200 S1 P3 400
P3 400 S1 P4 200
P4 200 S1 P5 100
P5 100 S1 P6 100
S2 P6 100 S2 P1 300
P1 300 S2 P2 400
S3 P2 400 S3 P2 200
S4 P2 200 S4 P2 200
P2 200 S4 P4 300
P4 300 S4 P5 400
P5 400

Suatu relation di katakan sudah berada pada 1NF jika dan hanya jika semua nilai
atributnya adala atomik (tunggal)

Contoh relation FIRST (S#,STATUS,CITY,P#,QTY), dimana STATUS atau CITY tidak

secara penuh tergantung pada primary key,STATUS dan CITY tidak mutually independent.
Primary key di sini adalah S#,P#

STATUS
QT S#
Y
P# CITY

18
FIRST

S# STATUS CITY P# QTY

S1 20 LONDON P1 300
S1 20 LONDON P2 200
S1 20 LONDON P3 400
S1 20 LONDON P4 200
S1 20 LONDON P5 100
S1 20 LONDON P6 100
S2 10 PARIS P1 300
S2 10 PARIS P2 200
S3 10 PARIS P2 200
S4 20 LONDON P2 200
S4 20 LONDON P4 300
S4 20 LONDON P5 400
Gambar 3. Functional Dependent dan contoh data di relasi FIRST

Di sini masih terdapat banyak kesulitan bila ingin melaksanakan operasidata misalnya :

INSERT : kita tidak dapat memasukan data pemasok yang berdomisili di suatu kota
sampai pemasok tersebut memasok paling tidak satu bahan. Di gambar 3
tidak terdapat S5 yng berdomisili di athena, karena S# Adalah merupakan
primary key bersama P# dan belum perna mengirim barang, maka tidak
boleh muncul, sehingga tidak boleh P# kosong (Null)

DELETE : bila misalnya kita hapus salh satu tuple, kita tidak hanya Kehilang data
tentang pengirim barang, tetapi juga data bahwa satu emasok berdomisili
di kota mana. Misalnya bila hapus tuple yang nilai S# = S3 dan P# = P2,
maka kita kehilangan data bahwa S3 berdomisili di paris

UPDATE : suatu kota muncul berulang-ulang, sehingga apabila kita akan merubah
bahwa S1 pindah dari london ke amsterdam, maka akan mendapatkan
persoalan untuk mencari semua S1 dan merubah london ke amsterdam
berikut statusnya yang berubah.

Pemecahan pertama adalah dengan memecah relation FIRST menjadi dua, yaitu
SECOND (S#,STATUS,CITY) dan SP(S#,P#,QTY). Contohnya dapat di lihat pada gambar
4, yang menggambarkan functional dependent serta isi relation SECOND dan SP. Di sini
sudah dapat di tambahkan pemasok S5 yang berdomisili di athena di relation SECOND,
tetapi tidak dapat di tambahkan di SP.

STATUS S
# QT
S#
Y
P
CITY
#
19
SECOND SP

S# STATUS CITY S# P# QTW

S1 20 London S1 P1 300
S2 10 Saris S1 P2 200
S3 10 Paris S1 P3 400
S4 20 London S1 P4 200
S5 30 Athena S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P2 200
S4 P2 200
S4 P4 300
S4 P5 400

Gambar 4. Functional Dependence dan contoh data di relation SECOND dan SP

Dari gambar pemecahan ini sudah akan mengurangi persoalan-persoalan operasi di

atas, baik insert, delete maupun update. Dengan struktur ini kita sudah menghilangkan
nonfull functional dependence. Sehingga kita dapat buat definisi dari tingkat normalisasi
berikutnya.

SECOND NORMAL FORM (2NF)

Suatu relation sudah berada pada 2NF, jika dan hanya jika sudah berada pada
1NF dan setiap atribut yang bukan key, fully functional dependency terhadap primary
key.

Reduksi relation FIRST ke SECOND dan SP adalah suatu contoh nonloss

decomposition. Relation SECOND dan SP adalah hahsil dari projection dari relation
FIRST, dan sebaliknya FISRST adalah hasil natural join dan relation SECOND dan SP.
Tetapi struktur SECOND di sini masih juga menimbulkan persoalan karena atribut-atribut
yang bukan key belum mutual independence. Ketergantungan (dependency)
STATUSterhadap S# adalah functional, tetapi masih tergantung juga terhadap CITY
(masih transitive dependence).

Bila setiap S# menentukan nilai CITY dan STATUS, dan kemudian CITY
menentukan juga nilai STATUS transitive dependence ini juga menimbulkan persoalan
terhadap operasi update antara STATUS dan CITY.

20
INSERT : Kita tidak dapat memasukan data bahwa suato kota mempunyai nilai
STATUS tertentu, misalnya kita tidak dapat menyatakan bahwa pemasok
barang dari ROMA harus mempunyai STATUS 50 sampai kita
mempunyai pemasok yang berada di kota tersebu. Alasannya adalah
sebelum pemasok tersebut muncul kita tidak punya nilai primary key.

DELETE : Bila kita hanya menghapus tuple suatu kota tertentu, kita menghapus tidak
data mengenai pemasok tersebutt. Misalnya bila kita menghapus tuple
yang berisi S5,kita kan kehilangan nilai status untuk kota Athena yang
berisi 30.

UPDATE : Nilai status kota dan relation SECOND muncul berkali-kali. Bila kita
ingin mengubah nilai status kota London dari 20 menjadi 3, maka kita
akan di berikan persoalan baik untuk pencairan semua kota dan juga
mungkin salah penulisan.

Cara memecahnya adalah dengan memecah relation SECOND menjadi dua dengan
operasi projection, yaitu SC(S#,CIITY) dan SC(CITY,STATUS), seperti di dapat di gambar
5. Dalam gambar 5 terlihat bahwa kita mengeliminasi transitive dependence dari STATUS
terhadap S#. sehingga kita dapat mendefinisikan tingkat normalisasi berikutnya yaitu 3NF.
SC CS
S# CITY CITY STATUS
S1 London Athena 30
S2 Paris London 20
S3 Paris Paris 10
S4 London
S5 Athena

Gambar 5. Functional dependence dan contoh data direlation SC dan CS

THIRD NORMAL FORM (3NF)

Suatu relation sudah berada pada 3NF bila sudah berada dalam 2NF dan
setiap atribut yang bukan key tidak dependent terhadap atribut lain (tidak transitive)

Kecuali primary key (nontransitively dependent terhadap primary key).

Dalam relation SC, atribut S# sebagai primary key, dan di dalam relation CS atribut
CITY sebagai Primary key.

Sifat transitif : a=b, b=c, maka a=c.

21
BOYCE/CODD NORMAL FORM (BCNF)

Definisi 3NF diperkuat lagi dan di sederhanakan dengen definisi dari BCNF, yaitu
tidak menunjuk ke 1NF, 2NF, maupun konsep full dan transitive dependence. Dalam
definisi ini kita pergunakan istilah (functional) determinant sebagai atribut diaman semua
atribut lainnya fully functionally deoendent terhadapnya.

Sehingga definisi dari suatuu relation itu sudah berada pada BCNF, bila setiap
determinant adalah merupakan candidate key.

Suatu relation yang sudah pada 3NF belum tentu pada BCNF,tetapi relation yang
sudah pada BCNF pasti pada 3NF.

Contoh : dalam gambar 5 relation STJ berada pada 3NF tetapi tidak pada BCNF
karena terjadi overlap candidate key (S,J) dan (S,T)

STJ

S J T
Smith Math Prof. White
Smith Physics Prof. Green
Jones Math Prof. White
Jones Physics Prof. Green

Gambar 6,functional dependence dancontoh data di relation STJ

FOURTH NORMAL FORM (4NF)

Dalam normalisasi ini kita mengenal adanya tipe baru dari ketergantungan
(dependency) yaitu Multivalued Dependency, (MVD), yang merupakan generalisasi dari
functional dependence. Atau sebaliknya. FD adalah peristiwa kusus dari MVD dimana
himpunan nilai dependent berisi satu nilai saja. Sebagai contoh relation di gambar 7 ini.

MTD

MTKUL DOSEN TEXT

Physics Prof. Green Basic Mechanics
Physics Prof. Green Principles of Optics
Physics Prof. Brown Basic Mechanics
Physics Prof. Brown Principles of Optics
Physics Prof. Black Basic Mechanics
Physics Prof. Black Principles of Optics
Math Prof. White Modern Algebra
Math Prof. White Projective Geometry
22
Mata kuliah physics di berikanoleh tiga dosen yaitu Prof. Green, Prof. Brown, Prof. White,
sedangkan mata kuliah Math di berikan oleh satu dosen yaitu Prof. White untukmata kuliah
physics mempergunakan dua text yaitu Modern Algebra dan Projective Geometry.

Relation ini berada pada BCNF karena tidak ada functional determinants lain kecuali
MTKUL. Tetapi kita lihat banyak duplikasi data, sehingga struktur ini dapat kita pecah
kecuali dua relation MD dan MT seperti pada gambar 8.

MTKUL DOSEN MTKUL TEXT

Physics Prof. Green Physics BasicMechanics
Physics Prof. Brown Physics Principles of Optics
Physics Prof. Black Math Modern Algebra
Math Prof. White Math Projective Geometry

Gambar 8. Relation MD dan MT

Terdapat dua MVD di relation MDT yaitu :

MDT.MTKUL ---- > ---- > MDT.DOSEN

MDT.MTKUL ---- > ---- > MDT.TEXT

Artinya atribut MDT.DOSEN multydependent terhadap atribut MDT.MTKUL atau

atribut MDT.MTKUL multidetermines atribut MDT.DOSEN. begitu juga untuk yang
kedua. Sehingga definisi dari MVD adalah :

Bila dalam suatu relation R terdapat atribut A, B, dan C multi …… dependence R.A
 R.B terjadi di R, bila himpunan darinilai B macth (cocok) dengan pasang nilai A danC
di R, hanya tergantungpada nilai A dan bebas terhadap nilai C.

R.A ---- > ---- > R.B | R.C

Contoh :

MDT.MTKUL ---- > ---- > MDT.DOSEN | MDT.TEXT

MVD terjadi hanya bila dalam relation mempunyai paling sedikit tiga atribut.

Definisi 4NF :

Suatu relation berada pada 4NF bila terjadi MVD di R yaitu A ---- > ---- > B.

Kemudian semua atribut di R juga Functionally dependent pada A.

4NF lebih baik dari BCNF Yaitu setiap relation 4NF berada pada BCNF. Semua relation
dapat nonloss decomposed ke dalam kumpulan 4NF relation.

23
 FIFTH NORMAL FORM (5NF) atau PROJECT-JOINNORMAL FORM (PJNF)

Suatu relation dapat terus dilakukan proses nonloss-decomposition sampai semua projection
berada pada 5NF. Tetapi hal inijuga ada keterbatasan yaitujoin dependency(JD), yaitu bila
projection dapat di lakukan sehingga tidak ada nilai yang hilang, apabila di join kembali. JD
adalah generalisasi dari MVD.

Suatu relation R barada pada 5NF bila setiap join dependency di R di buat dengan candidate
key di R.

Contoh :
SPJ

S# P# J#
S1 P1 J2
S1 P2 J1
S2 P1 J1
S1 P1 J1

S# P# P# J# J# S#
S1 P1 P1 J2 J2 S1
S1 P2 P2 J1 J1 S1
S2 P1 P1 J1 J1 S2

Join pada P#

Join pada (J#,S#)

S# P# J#
S1 P1 J2
S1 P1 J1
SPJ awal
S1 P2 J1
S2 P1 J2 Gambar 9. Relation SPJ dengan operasi join dari
S2 P1 J1 projection-projectionnya

Beberapa persoalan update di SPJ adalah seperti contoh pada gambar 10.

S# P# J#

S1 P1 J2

S1 P2 J1

24
 KESIMPULAN
Tahap-tahap roses reduksi pada normalisasi, yaitu :
1. ambil projection pada relation 1NF awal untuk mengeliminasi semua nonfull
functional dependence, sehingga menghasilkan relation 2NF.
2. ambil projection pada relation 2NF untuk mengeliminasi semua transitive
dependence, sehingga menghasilkan kumpulan relation 3NF.
3. ambil projection pada relation 3NF untuk mengeliminasi semua sisa functional
dependence dimana determinannya bukan candidate key, sehingga
menghasilkan relation BNCF.
Catatan : tahap 1 sampai dengan 3 dapat di persingkat sebagai berikut :
Ambil projection dari relation awal untuk mengeliminasi semua FD
dimana determinannya bukan candidate key.
4. ambil projection pada reklation BNCF untuk mengeliminasi MVD yang bukan
FD juga, sehingga menghasilkan kumpulan relation 4NF.
5. ambil projection pada relation 4NF u ntuk mengeliminasi semua JD yang bukan
implementasi dasri candidate key.

Seseorang ahli (fagin) menambahkan suatu tingkat normalisasi yaitu (3.3)NF sebagai
peningkatan dari 3NF, serupa dengan BNCF, bukan merupakan 4 NF. Selain itu juga
menambahkan satu tingkat normalisasi lagi yaitu DK/NF (domain Key Normal Form ) yang
tidak menyinggung sama sekali tentang FD, MVD maupun JD. DK/NF terjadi bila setiap
relation yang terjadi memenuhi batasan-batasan (constraints) tertentu yaitu sebagai akibat
dari batasan key ( key constraints ) dan batasan domain (domain constraints).
Key constraints adalah ketentuan/ batasan tentang atribut atau kombinasinya yang
merupakan candidate key.
Domain constraints adalah ketentuan/batasan dimana nilai atribut tertentu berada pada
himpunan nilai yang sudah di tentukan batasan-batasannya.
Di nyatakan juga bahwa DK/NF juga otomatis 5NF,sehingga juga 4NF dan (3.3)NF.
DK/NF tidak harus selalu tercapai dan tidak juga terjawabnya pertanyaan secara pasti kapan
hal tersebut dapat tercapai.

25