Data Modelling Using the

Entity Relationship Model

Minggu 3 dan 4
Rusydi Umar, S.T. M.T.
Teknik Informatika UAD
Tujuan dan manfaat

Menjelaskan konsep pemodelan dari

Entity-Relatinoship (ER) Model
ER Model sering disebut juga
konseptual data model tingkat tinggi
Digunakan untuk merancang konsep
aplikasi basis data
Banyak tools perancangan basis data
menggunakan konsep ini
Perancangan Basis Data menggunakan
Konsep Model Data Tingkat Tinggi
Mengumpulkan dan menganalisa
kebutuhan
Wawancara dengan pengguna untuk
mengetahui mendokumentasikan
kebutuhan data pengguna
Diusahakan selengkap mungkin dan
sedetil mungkin
Disamping itu juga penting untuk diketahui
kebutuhan fungsional pengguna yang
berisi operasi-operasi yang di akan
diterapkan pada basis data, termasuk
membaca, dan menulis basis data
Data Flow Diagram (DFD)

Untuk menspesifikasikan kebutuhan

fungsional pengguna, digunakan data
flow diagram.
Lebih lanjut tentang data flow diagram
dapat dilihat di mata kuliah rekayasa
Perangkat Lunak
Perancangan Basis Data menggunakan
Konsep Model Data Tingkat Tinggi
Langkah berikutnya adalah Merancang
Basis Data Konseptual
Yaitu membuat Skema Konseptual untuk
Basis Data menggunakan Konsep Model
Data Tingkat Tinggi
Skema ini berisi penjelasan tentang
kebutuhan data dan tipe data, hubungan
dan batasan
Karena tidak berhubungan dengan media
penyimpanan maka mudah
dikomunikasikan dengan pengguna non
teknis
Perancangan Basis Data
Lojik/Pemetaan Model Data
Langkah berikutnya adalah
implementasi dari basis data.
Kebanyakan DBMS menggunakan
data model, maka langkah
selanjutnya mengubah skema
konseptual menjadi model data
implementasi
Langkah terakhir Merancang Basis
Data Fisik
Contoh Kasus : Basis Data
Perusahaaan (Company)
Mengumpulkan kebutuhan data
Membuat Skema Konseptual langkah
demi langkah sekaligus
memperkenalkan konsep pemodelan
dari model ER
Hasil Dari pengumpulan kebutuhan
pengguna adalah sebagai berikut
Basis Data Perusahaan
Perusahaan terdiri dari departemen-
departemen. Departemen mempunyai
nama yang unik, nomor yang unik,
manager, mulai-kerja dari manager,
departemen mungkin berada di beberapa
lokasi
Departemen mengontrol beberapa proyek,
masing-masing mempunyai nama yang
unik, nomer yang unik, dan menempati
satu lokasi terntentu
Basis Data Perusahaan
Perusahaan mempunyai karyawan-karyawan.
Karyawan mempunyai data tentang nama, nomer
ID, alamat, gaji, jenis kelamin, tgl lahir. Tiap
karyawan berada di bawah satu departemen tapi
dapat melaksanakan beberapa proyek yang
proyek2 tersebut tidak harus dikontrol oleh
departemen yang sama. jam-kerja/minggu/proyek
dari karyawan dicatat, tiap karyawan mempunyai
supervisor
Karyawan mempunyai data tentang tanggungan
untuk keperluan asuransi, masing-masing
tanggungan memiliki data nama, jenis kelamin, tgl
lahir dan hubungannya dengan karyawan
Skema ER diagram untuk Basis Data Perusahaan
Entities and Attributes
Objek dasar dari model ER adalah entitas
Objek riil yang dapat dibedakan satu
dengan lainnya dan keberadaanya tidak
saling bergantungan
Entitas mungkin berupa objek yang bersifat
fisik. Contoh : mobil, pegawai, rumah
Entitas Konseptual, Secara fisik tidak ada,
entitas yang bersifat konsep. Contoh :
perusahaan, pekerjaan, mata kuliah
Entities and Attributes
Entities and Attributes
Tiap entitas mempunyai karakteristik tertentu
yang disebut Attributes, yang
menggambarkan entitas.
Contoh, Entitas Karyawan dapat
digambarkan dengan namanya, umur,
alamat, gaji.
Entitas tertentu akan mempunyai nilai
tertentu dari tiap atributnya
Attribute adalah Sifat yang digunakan untuk
membedakan instance entitas dengan
instance entitas yang lain
Types of Attrributes

Simple (Sederhana) vs Composite

(Komposit)
Single-valued (bernilai tunggal) vs
multivalued (bernilai banyak)
Stored (tersimpan) vs derived
(turunan)
Simple (Sederhana) vs Composite
(Komposit)
Atribut komposit : atribut yang terdiri
dari beberapa atribut yang lebih
mendasar
Contoh : Atribut alamat dapat terdiri
dari Nama Jalan dan No Rumah
Atribut sederhana/atomik : atribut yang
tidak dapat dibagi-bagi menjadi atribut
yang lebih lebih mendasar
Contoh : Atribut umur
Hirarki dari atribut komposit
Single-valued (bernilai tunggal) vs
multivalued (bernilai banyak)
Atribut Berharga Tunggal (Single-valued
Attribute) : atribut yang hanya mempunyai
satu harga untuk suatu entitas tertentu.
Contoh : atribut umur hanya mempunyai satu
nilai untuk satu entitas, misal 20th
Atribut Berharga Ganda (Multi-valued
Attribute) : atribut yang dapat terdiri dari
sekumpulan harga untuk suatu entitas
tertentu
Contoh : atribut warna dari mobil, mungkin
sebuah mobil mempunyai banyak warna
yaitu hitam, biru dan merah.
Stored (tersimpan) vs derived
(turunan)
Dalam beberapa kasus sebuah atribut
berhubungan dengan atribut yang lain.
Contoh : atribut umur berhubungan dengan
atribut tanggal lahir.
Untuk orang tertentu atribut umur dapat
dihitung dengan mengurangi tanggal
sekarang dengan tanggal lahir.
Maka atribut umur disebut dengan atribut
turunan, yaitu diturunkan dari tanggal lahir.
Atribut tanggal lahir ini maka disebut
sebagai atribut tersimpan.
Atribut yang komplek dari
AddressPhone
Dua entitas EMPLOYEE dan COMPANY dan
anggotanya
Tipe entitas CAR dan atributnya
Null Value
Dalam beberapa kasus mungkin terjadi
tidak ada sebuah nilai pun yang dapat
dimasukkan kedalam atribut.(bermakna not
applicable)
Contoh : Jenjang pendidikan, atribut ini
hanya mempunyai nilai untuk orang yang
pernah bersekolah dan tamat
Untuk kasus tersebut dibuatlah nilai null
Nilai null juga digunakan bila nilai dari
suatu atribut tidak diketahui (bermakna
unknown)
Entity Types,
Entity Types (Tipe Entitas) adalah
sekumpulan entitas yang mempunyai
atribut yang sama
Tipe entitas dalam diagram ER
dilambangkan dengan kotak.
Atribut dilambangkan dengan oval dan
dihubungkan dengan tipe entitasnya
melalui sebuah garis
Extension adalah sebagian dari tipe entitas
Atribut Kunci (Key Attribute) :
identifier unik dari suatu entitas karena nilai dari
atribut kunci ini akan berbeda untuk masing-
masing entitas
dapat terdiri dari atribut sederhana/ komposit
Contoh :
NomorMobil dari entitas MOBIL  komposit
NIM dari entitas mahasiswa  sederhana
Dalam diagram ER atribut kunci diberi garis
bawah.
Atribut kunci tidak boleh mempunyai harga yang
sama untuk entitas yang berbeda
Value Sets (Domains) of Attributes

kumpulan harga/nilai yang dapat

dimiliki oleh atribut dari suatu entitas
Contoh :
Atribut umur karyawan domainnya 16
sampai 70
Atribut nama pada entitas barang
domainnya nama barang (sekumpulan
karakter.)
Desain Konseptual Awal dari Basis
Data Perusahaan (1)
Berdasarkan hasil wawancara dengan
pengguna tentang kebutuhan basis data
pengguna, maka dapat ditentukan empat
tipe entitas
Tipe entitas Department dengan atribut
Name, Number, Locations, Manager dan
ManagerStartDates. Satu-satunya
multivalued attribute adalah Locations. Atribut
kuncinya adalah Name dan Number
Desain Konseptual Awal dari Basis
Data Perusahaan (2)
1. Tipe entitas Project, dengan atribut Name, Number,
Location, dan ControllingDepartment. Atribut kuncinya
adalah Name dan Number
2. Tipe entitas Employee, dengan atribut Name, SSN,
Sex, Address, Salary, BirthDate, Department, dan
Supervisor. Name dan Address mungkin atribut
komposit, karena tidak ditentukan saat wawancara
pertama, maka temui kembali pengguna untuk
menentukannya.
3. Tipe entitas Dependent, dengan atribut Employee,
DependentName, Sex, BirthDate, dan Relationship
(hubungan dengan karyawan)
Beberapa hal yang tak terlihat
adalah
Jumlah jam kerja perminggu karyawan
yang bekerja pada proyek tertentu 
karakteristik ini diperoleh dari wawancara
 solusinya :
Dibuat menjadi atribut composite multivalued
pada Employee yang disebut WorksOn dengan
komponen (Project, Hours)
Atau dapat dibuat menjadi atribut composite
multivalued dari Project yang disebut Workers
dengan komponen (Employee, Hours)
Preliminary Design
DEPARTMENT
Name, Number, {Locations}, Manager,
ManagerStartDate

PROJECT
Name, Number, Location, Controlling Department

EMPLOYEE
Name(Fname, Minit, Lname), SSN, Sex, Address,
Salary, BirthDate, Department, Supervisor,
{WorksOn(Project, Hours)}

DEPENDENT
Employee, DependentName, Sex, BirthDate,
Relationship
Implicit Relationship
Jika atribut dari salah satu entitas merujuk pada
entitas yang lain maka, muncul relationship.
Atribut Manager dari entitas Department merujuk
pada karyawan yang memimin Departemen
Atribut ControllingDepartment dari Project merujuk
pada departemen yang mengontrol Project
Atribut Supervisor dari entitas Employee merujuk
pada Employee (yang berperan sebagai
supervisee dari karyawan ini)
Atribut Department dari Empolyee merujuk pada
Departement dimana Employee bekerja
Dll
Implicit Relationship

Dalam model ER, rujukan ini tidak di

wakili oleh atribut tetapi oleh
relationship.
Dalam desain awal relationship pada
umumnya tetangkap sebagai atribut
Dengan perbaikan desain maka
atribut tersebut diubah menjadi
relationship
Relationships

Relationship Types R diantara n

entitas E1, E2, ….En mendefinisikan
sekumpulan asosiasi diantara entitas
dari tipe tersebut
R adalah sekumpulan relationship
instance ri
Lihat contoh berikut :
Relationships
Degree of relationship type
Derajat relasi adalah jumlah tipe
entitas yang berpartisipasi dalam
relasi.
Derajat relasi WORKS_FOR adalah
2.
Relasi yang berderajat 2 disebut
binary relationships.
Relasi yang berderajat 3 disebut
ternary relationships.
Ternary relationship
Role names and recursive
relationships
Masing-masing tipe entitas memegang
peranan dalam hubungan antar tipe entitas
(relationship).
Nama peran menjadi penting bila tipe entitas
yang sama terlibat lebih dari satu kali pada
satu relationship dengan peran yang berbeda.
Relationship seperti ini dikenal dengan
sebutan recursive relationship.
Nama peran TIDAK PENTING bila semua tipe
entitas yang terlibat tidak ada yang sama,
karena nama entitas bisa mewakili menjadi
peran sekaligus
Role names and recursive relationships
Constraints on relationship types

TOTAL
semua karyawan HARUS bekerja pada
suatu departemen (harus)
PARTIAL
beberapa dari karyawan memimpin
suatu departemen (tidak semua)
Cardinality Ratio
Adalah jumlah dari relationship instance yang
dapat diikuti oleh entitas
1 : 1 : satu entitas pada tipe entitas A
berhubungan dengan satu entitas pada tipe entitas
B dan juga sebaliknya, seorang manager hanya
memimpin satu departemen
1 : N : suatu entitas di A dihubungkan dengan
sejumlah entitas di B, satu departemen memiliki
banyak karyawan
M : N : sejumlah entitas di A dihubungkan dengan
sejumlah entitas di B,satu proyek mempunyai
banyak karyawan, satu karyawan boleh bekerja di
beberapa proyek
M:N Relationships
Attribut of Relationship Types

Tipe relasi juga bisa mempunyai

atribut.
Contoh, untuk mencatat jumlah jam
perminggu dari karyawan yang
mengerjakan proyek, dapat
ditambahkan atribut Hours pada relasi
WORKS_ON
Attribut of Relationship Types (1)
Atribut dari relasi 1:1 atau 1:N dapat
dipindah-pindahkan dari masing-
masing entitas yang berpartisipasi
dalam relasi tersebut.
Contoh : Atribut StartDate dari relasi
MANAGES dapat diletakkan di entitas
EMPLOYEE atau DEPARTMENT
Tapi secara konseptual atribut
StartDate adalah miliknya relasi
MANAGES
Attribut of Relationship Types (2)
Untuk relasi 1:N atribut relasi hanya
dapat dipindahkan ke entitas yang N
Contoh : dalam relasi WORKS_FOR
terdapat relasi StratDate diletakkan
dalam entitas EMPLOYEE
Untuk relasi N:N atribut relasi
ditentukan berdasarkan dari entitas
yang berpartisipasi dalam relasi
tersebut.
Weak Entity Type
Entitas yang tidak mempunyai atribut
kunci
Entitas dari WET dapat diidentifikasi
dengan entitas lain yang berelasi
dengan WET tersebut.
Entitas lain tersebut disebut identifying
owner.
Relasinya disebut identifying
relationship
Weak Entity Type (2)
WET selalu mempunyai batasan
keikutsertaan TOTAL (existence
dependency), karena WET tidak dapat
diidentifikasi tanpa entitas pemiliknya
Tidak semua existence dependency
merupakan WET
Contoh : Entitas SIM tidak dapat
muncul tanpa ada pemiliknya, dan
entitas SIM mempunyai kunci, maka
entitas SIM bukan WET
Weak Entity Type (3)
Contoh : Entitas DEPENDENT dengan
atribut DependentName, BirthDate,
Sex, dan Relationship dengan
EMPLOYEE
Dua DEPENDENT dari EMPLOYEE
yang berbeda mungkin mempunyai
nilai yang sama untuk atribut
DependentName, BirthDate, Sex, dan
Relationship, tetapi keduanya tetap
dianggap sebagai entitas yang
berbeda
Weak Entity Type (4)
WET biasanya mempunyai partial key,
yaitu sekumpulan atribut yang dapat
membedakan entitas yang satu
dengan yang lainnya dalam WET
Dapa juga digambarkan dengan
multivalued composite attribut
Partial key digambarkan dengan garis
bawah putus2
Refining ER design
Design pada halaman 25 dapat
dihaluskan dengan menambahkan
dengan :
Meletakkan atribut milik relasi ke relasi
Menentukan cardinality ratio dan
participation constrain dari tiap relasi
Bila cardinality ratio dan participation
constrain tidak dapat ditentukan maka
desainer dapat kembali ke pengguna
untuk menanyakan hal tersebut
Tipe Relationship
MANAGES,
Realsi 1:1 dari EMPLOYEE dan
DEPARTMENT
EMPLOYEE mempunyai batasan
keikutsertaan partial
DEPARTMENT mempunyai batasan
keikutsertaan total
Atribut relasi adalah StartDate
Tipe Relationship
WORKS_FOR,
Realsi N:1 dari EMPLOYEE dan
DEPARTMENT
EMPLOYEE mempunyai batasan
keikutsertaan total
DEPARTMENT mempunyai batasan
keikutsertaan total
Atribut relasi tidak ada
Tipe Relationship
CONTROLS,
Realsi 1:N dari DEPARTMENT dan
PROJECT
PROJECT mempunyai batasan
keikutsertaan total
DEPARTMENT mempunyai batasan
keikutsertaan partial
Atribut relasi tidak ada
Tipe Relationship
SUPERVISION,
Realsi 1:N dari EMPLOYEE (sebagai
sepervisor) dan EMPLOYEE (sebagai
supervisee)
EMPLOYEE mempunyai batasan
keikutsertaan partial
EMPLOYEE mempunyai batasan
keikutsertaan partial
Atribut relasi tidak ada
Tipe Relationship
WORKS_ON,
Realsi M:N dari EMPLOYEE dan
PROJECT
EMPLOYEE mempunyai batasan
keikutsertaan total
PROJECT mempunyai batasan
keikutsertaan total
Atribut relasi adalah Hours
Tipe Relationship
DEPENDENT_OF,
Realsi 1:N dari EMPLOYEE dan
DEPENDENT (identifying relationship)
EMPLOYEE mempunyai batasan
keikutsertaan partial
DPENDENT mempunyai batasan
keikutsertaan total
Atribut relasi adalah tidak ada
ER diagram
Notasi Alternatif
Notasi alternatif untuk structural
constraint adalah dengan pasangan
angka (min, max)
angka ini menunjukkan relationship
instance dari entitas ybs
nilai min dan max adalah 0≤min≤max
dan max≥1
min = 0 berarti partial participaton
min > 0 berarti total participation
Skema ER diagram untuk Basis Data Perusahaan
Skema konseptual perusahaan dalam
class diagram UML
Ternary relationships
Derajat dari relationship yaitu binary
dan ternary
Ternary  Binary Relationships
branches branches

?? CB
customers accounts AB
CAB

customers CA accounts

CAB tidak dapat dipresentasikan sebagai three binary relationships:

Alasan : binary relationships tidak dapat menangkap secara tepat informasi
yang direpresentasikan oleh ternary relationship.
AB CA CB
Customer Branch Account
Branch Account Customer Account Customer Branch
C2 B1 A1 B1 A1 C2 A1 C2 B1
C1 B1 A2 B1 A2 C1 A2 C1 B1
B2 A2 C2 A2
C2 B2 A2 C2 B2

CAB relationships Relationships for the new ER diagram (after projections)

65
 Ternary  Binary Relationships
branches branches

?? CB
customers accounts AB
CAB

customers CA accounts

Tapi kumpulan relasi dari diagram asal dapat menghasilkan kumpulan

binary relationship yang sama persis
Dengan menggunakan three binary relationships, bagaimana cara
mengetahui bahwa entitas (C2,B1,A2) ada atau tidak?  Informasi ini
hilang saat translasi.
Customer Branch Account AB CA CB
C2 B1 A1 Branch Account Customer Account Customer Branch
C1 B1 A2 B1 A1 C2 A1 C2 B1
C2 B2 A2 B1 A2 C1 A2 C1 B1
B2 A2 C2 A2 C2 B2
C2 B1 A2
66

Another set of CAB relationships Relationships for the new ER diagram (after projecti
Ternary Binary Relationships (cont)
CAB’
branches

customers accounts C’ B’
CAB A’

customers branches accounts

CAB direpresentasikan sebagai weak entity set

CAB’ (called “connecting ES”)
Skema menggunakan binary relationships
menangkap seluruh informasi yang ada di ternary
relationship.
67
Ternary relationship
types.
(a) The SUPPLY
relationship.
(b) Three binary
relationships not
equivalent to SUPPLY.
(c) SUPPLY represented
as a
weak entity type.

68