Bab 8

Entity Relationship
Diagram (Diagram
Hubungan antara Entitas)

8.1 PENGANTAR

B ab ini membahas bagaimana professional system 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 system secara abstrak. Jadi, jelaslah bahwa ERD ini berbeda
dengan DFD yang merupakan suatu model jaringan fungsi yang akan dilaksanakan oleh
system, sedangkan ERD merupakan model jaringan data yang menekankan pada struktur-
struktur dan relationship data.

Biasanya ERD ini digunakan oleh professional system untuk berkomunikasi dengan
pemakai eksekutif tingkat tinggi dalam suatu organisasi (seperti wakil presiden direktur
dan manajer yang tidak tertarik pada pelaksanaan operasi-operasi system sehari-hari).
Pemakai ini lebih tertarik dengan hal-hal sebagai berikut:
• Data apa saja yang dibutuhkan untuk bisnis mereka?
• Bagaimana data tersebut berelasi dengan data lainnya?
• Siapa saja yang diperkenalkan untuk mengakses data tersebut?

ERD juga menguntungkan bagi professional system, karena ERD memperlihatkan

hubungan antar data store pada DFD (dapat dilihat pada BAB XI: Implementasi Basis
Data Dalam Proyek Pengembangan Sistem Informasi). Hubungan ini tidak terlihat
pada DFD, karena DFD hanya memusatkan perhatian pada fungsi-fungsi system bukan
pada data yang dibutuhkan.

Diagram hubungan entitas atau yang lebih dikenal dengan sebutan E-R diagram,
adalah notasi grafik dari sebuah model data atau sebuah model jaringan yang
menjelaskan tentang data yang tersimpan (storage data) dalam system secara abstrak.
Diagram hubungan entitas tidak menyatakan bagaimana memanfaatkan data, membuat
data, mengubah data, dan menghapus data.
8.2 ELEMEN-ELEMEN DIAGRAM HUBUNGAN ENTITAS

8.2.1 ENTITY
Pada E-R diagram, entity digambarkan dengan sebuah bentuk persegi panjang. Entity
adalah sesuatu apa saja yang ada di dalam system, nyata maupun abstrak dimana data
tersimpan atau dimana terdapat data. Entitas diberi nama dengan kata benda dan dapat
dikelompokkan dalam empat jenis nama, yaitu orang, benda, lokasi, kejadian(terdapat
unsur waktu di dalamnya).

8.2.2 RELATIONSHIP
Pada E-R diagram, relationship dapat digambarkan dengan sebuah bentuk belah
ketupat. Relationship adalah hubungan alamiah yang terjadi antara entitas. Pada
umumnya penghubung (relationship) diberi nama dengan kata kerja dasar sehingga
memudahkan untuk melakukan pembacaan relasinya (bisa dengan kalimat aktif atau
kalimat pasif). Penggambaran hubungan yang terjadi adalah sebuah bentuk belah ketupat
dihubungkan dengan dua bentuk empat persegi panjang.

Contohnya, Entitas Mahasiswa dengan NIM = “14534” dan Nama_Mhs = “Yudin” yang
memepunyai relasi dengan Entitas Kuliah dengan Kode_Kul = “SI-140” dan Nama_MK
= “Basis Data”, sehingga struktur data dari Relasi ini bahwa mahasiswa tersebut
mengambil mata kuliah pada suatu perguruan tinggi.

Sedangkan kita juga mengenal adanya Himpunan Relasi, yaitu kumpulan semua
relasi di-antara entitas-entitas yang terdapat dalam himpunan entitas-himpunan entitas,
tetapi pada umumnya himpunan relasi sering disebut dengan Relasi saja.

Illustrasinya sebagai berikut.

Tabel 8.1 Entitas / Tabel kuliah

Entitas Kuliah
Kode_Kul Nama_MK SKS Semester
SI-140 Basis Data 4 3
PA-100 Pancasila 2 1
MT-140 Kalkulus 4 4
Tabel 8.2 Tabel / Entitas kuliah

Relasi Entitas Mahasiswa Entitas Kuliah

NIM Nama_Mhs .....

14534 Yudin .....
14251 Nurhasan .....
14782 Yanah .....
Kode_Kul Nama_MK ….
SI-140 Basis Data ….
PA-100 Pancasila ….
MT-140 Kalkulus ….

8.2.3 RELATIONSHIP DEGREE

Relation degree atau Derajat Relationship adalah jumlah entitas yang berpartisipasi
dalam satu relationship Derajat Relationship yang sering dipakai di dlam ERD sebagai
berikut.

8.2.3.1Unary Relationship

Contoh:

Pegawa Menikah
i

Gambar 8.1 (a) Diagram Relationship Unary.

Pada Ganbar 8.1 (a) relationship Menikah menunjukkan relationship satu-ke-satu

antara instance-instance dari entitas PEGAWAI.

8.2.3.2 Binary Relationship

Binary Relationship adalah model Relationship antara instance-instance dari suatu tipe
entitas (dua entity yang berasal dari entity yang sama). Relationship ini paling umum
digunakan dalam pembuatan mode data. Gambar di bawah ini 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

Contoh:

M Bekerja N
PEGAWAI DEPT.
untuk

Gambar 8.1 (b) Diagram Relationship Binary

8.2.3.3 TERNARY RELATIONSHIP

Ternary Relationship merupakan relationship antara instance-instance dari tiga tipe
entitas secara serentak . poada gambar 8.1 (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.

Alat

Pegawai Bekerja Pegawai

Utk

Jumlah

Gambar 8.1 Diagram Relationship Ternary

8.2.4 ATRIBUT
Secara umum atribut adalah sifat atau karakteristik dari tiap entitas maupun tiap
Relationship. Maksudnya, atribut adalah sesuatu yang menjelaskan apa sebenarnya yang
dimaksud entitas maupun Relationship sehingga sering dikatakan bahwa atribut adalah
elemen dari setiap entitas dari Relationship.

8.2.4.1 Atribut Value

 Atribut value atau nilai attribute adalah suatu occurrence teretntu dari sebuah attribute
di dalam suatu entity atau Relationship.

Ada dua jenis atribut antara lain sebagai berikut.

a. Identifier (key) digunakan untuk menentukan suatu entity secara unik (primary key).
b. Descriptor (nonkey attribute) digunakan untuk menspesifikasikan karakteristik dari
suatu entity yang tidak unik.

8.2.5 KARDINALITAS (CARDINALITY)

Kardinalitas Relasi menunjukkan jumlah maksimum tupel yang dapat berelasi
dengan entitas pada entitas yang lain. Pada contoh sebelumnya, dapat melihat bahwa
tupel-tupel pada emas Mahasiswa dapat berelasi dengan satu tupel, banyak tupel, atau
bahkan tidak satupun tupel dari entitas Kuliah.Begityu pula sebaliknya, entitas-entitas
pada entitas kuliah ada yang berelasi dengan beberapa tupel pada entitas Mahasiswa dan
ada pula yang berelasi dengan satu tupel pada entitasa Mahasuswa.

8.2.5.1 One to One

Tingkat hubungan ini menunjukkqn hubungan satu ke satu, dinyatakan dengan satu
kejadian pada entitas pertama, dan hanya mempunyai satu hubungan dengan satu
kejadian pada entitas yang kedua dan sebaliknya.

Artinya setiap tupel pada entitas A berhubungan dengan paling banyak satu tupel
pada entitas B, dan begitu juga sebaliknya setiap tupel pada entitas B berhubungan
dengan paling banyak satu tupel pada entitas A.

8.2.5.2 One to Many atau Many to One

Tingkatkan hubungan satu ke banyak adalah sama dengan banyak ke satu, tergantung
dari arah mana hubungan tersebut dilihat. Untuk satu kejadian pada entitas yang pertama
dapat mempunyai banyak hubungan dengan kejadian pada entitas yang kedua.
Sebaliknya, satu kejadian pada entitas yang kedua hanya dapat mempunyai satu
hubungan dengan satu kejadian pada entitas yang pertama.

One to Many (satu ke banyak)

Yang berarti satu tupel pada entitas A dapat berhubungan dengan banyak tupel pada
entitas B, tetapi pada entitas sebaliknya, dimana setiap tupel pada entitas B, berhubungan
dengan paling banyak satu tupel pada entitas A.

Many to One (banyak ke satu)

Yang berarti setiap tupel pada entitas BA dapat berhubungan dengan paling banyak
satu tupel pada entitas B, tetapi tidak sebaliknya, di mana setiap tupel pada entitas A
berhubungan dengan paling banyak satu tupel pada entitas B.

8.2.5.3 Many to Many

Tingkat hubungan banyak ke banyak terjadi jika tiap kejadian pada sebuah entitas
akan mempunyai banyak hubungan dengan kejadian pada entitas lainya, dilihat dari sisi
entitas yang pertama maupun dilihat dari sisi yang kedua.
 Artinya setiap tupel pada entitas A dapat berhubungan dengan banyak tupel pada
entitas B, dan sebaliknya, di mana setiap tupel pada entitas B dapat berhubungan dengan
banyak tupel pada entitas A.

8.3 NOTASI (DIAGRAM E-R)

Notasi-notasi simbolik di dalam Diagram E-R yang dapat kita gunakan adalah sebagai
berikut.
• Persegi panjang, menyatakan Himpunan Entitas / entitas.
• Lingkaran / Elips, menyatakan Atribut (Atribut yang berfungsi sebagai key digaris
bawahi)
• Belah Ketupat, menyatakan Himpunan Relasi /relasi.
• Garis, sebagai penghubung anatra Himpunan Relasi dengan Himpunan Entitas dan
Himpunan Entitas dengan Atributnya.
• Kardinalitas Relasi dapat dinyatakan dengan banyaknya garis cabang atau dengan
pemakaian angka (1 dan 1 untuk relasi satu-ke-satu, 1 dan N untuk relasi sqatu-ke-
satu-ke-banyak atau N dan N untuk relasi banyak-ke-banyak).

E Himpunan Entitas E

a Atribut a sebagai key

R Himpunan Relasi R

Link

Berikut adalah contoh aktual penggambaran relasi antar himpunan entitas lengkap
dengan kardinalitas relasi dan atribut-atributnya:

8.3.1 CONTOH KASUS PENGGAMBARAN KARDINALITAS

RELASI DENGAN ERD VERSI CHEN

8.3.1.1 Relasi satu-ke-satu (one-to-one)

Contoh:
 Adanya relasi antara entitas Dosen dengan antitas Jurusan. Relasinya kita beri
nama’Kepalai’. Pada relasi ini, setiap dosen paling banyak mengepalai satu jurusan
(walaupun memang tidak semua dosen yang menjadi ketua jurusan). Setiap jurusan
dikepalai oleh paling banyak satu orang dosen. Maka penggambarannya adalah sebagai
berikut.

NID
NID

1 1
Dosen  Kepala  Jurusan

Gambar 8.2 (a) Diagram Kardinalitas One to One

Catatan:
Pada setiap kejadian hubungan/kardinalitas relast satu ke satu dapat ditangani dengan
menyamakan primary key masing-masing entitas. Penyamaan primary key ini
dilakukan hanya untuk memudahkan daya ingat kita. Apabila primary key pada salah
satu entitas tersebut dengan nama primary key yang sama pada entitas pasangannya.

8.3.1.2 Relasi satu-ke-banyak (one-to-many)

Contoh:

Adanya relsi antara entitas Dosen dengan entitas Kuliah. Relasinya kita beri nama
‘Ajar’. Pada relasi ini, setiap dosen dapat mengajar lebih dari satu mata kuliah, sedang
setiap mata kuliah diajar hanya oleh paling banyak satu orang dosen. Maka
penggambarannya adalah sebagai berikut.

NID
NID Kd_MK

1 M
Dosen  Ajar  Kuliah

Gambar 8.2 (b) Diagram Kardinalitas One to Many

 Catatan:
Pada setiap kejadian hubungan/kardinalitas relasi satu ke banyak dapat ditangani dengan
cara menaruh primary key yang berada pada sisi relasi/entitas satu ke entitas/relasi yang
banyak, maka entitas yang banyak akan selalu memiliki foreign key di man keynya
berasal dari entitas/relasi yang satu. Seperti terlihat pada ERD di atas, NID pada entitas
dosen berfungsi sebagai primary key. Edangkan NID pada entitas Kuliah berfungsi
sebagai foreign key, semetara primary key pada entitas Kuliah adalah Kd_MK.

8.3.1.3 Relasi banyak-ke-banyak (many-to-many)

Contoh:

Adanya relasi entitas Mahasiswa dengan entitas Kuliah. Relasinya kita beri nama
‘Belajar’. Pada relasi ini, setiap mahasiswa dapat mempelajari lebih dari satu mata kuliah.
Demikian juga sebaliknya, setiap mata kuliah dapat dipelajari oleh lebih dari satu orang
mahasiswa. Maka penggambarannya adalah sebagai berikut.

NIM NIM Kd_MK Kd_MK

M N
Mahasiswa  belajar  Kuliah

Gambar 8.2 (c) Diagram Kardinalitas Many to Many

Catatan:
Pada setiap kejadian hubungan/kardinalitas relasi banyak ke banyak dapat ditangani
dengan cara membuat file konektor (file baru sedemikian sehingga relasi langsung
banyak ke banyak berubah menjadi relasi tidak langsung satu lawan banyak melalui
file konektor. Isi file konektor adalah minimal berisi dua primary key yaitu satu
dari entitas Dosen, dan satu lagi dari entitas Kuliah, maka pada setiap kasus
kardinalitas relasi Banyak ke Banyak akan menghasilkan tiga relasi baru. Seperti
telihat pada ERD di atas, Entitas Mahasiswa dengan primary key: NIM, entitas
Kuliah dengan primary key: Kd_MK, serta entitas Belajar dengan primary key
NIM + Kd_MK (entitas belajar merupakan file konektor), sementara atribut NIM
pada entitas (file konektor) Belajar berfungsi sebagai foreign key dari entitas
Mahasiswa, dan Kd_MK pada entitas (file konektor) Belajar berfungsi sebagai
foreign key dari entitas Kuliah. Dengan demikian maka kardinalitas relasi banyak
ke banyak di atas telah berubah (seolah-olah) menjadi satu ke banyak.

8.3.2 DIAGRAM ER VERSI JAMES MARTIN

 Di samping pemakaian notasi yan gsudah dijelaskan sebelumnya, dalam bebagai
literatur akan dapat dijumpai pula penggambaran diagram E-R yang sedikit berbeda
dengan yang telah kita gunakan. Penggambaran ini dikenalkan oleh James Martin.

Mahasiswa belajar | Kuliah || Ajar

|Dosen

Gambar 8.3 Diagram E-R dalam Notasi James Martin

Pada diagram E-R tersebut, perbedaannya terletak pada penggambaran derajat relasi
yang sekaligus juga telah mengakomodasi adanya Derajat Relasi Minimum.

Tabel 8.3 Tabel ERD versi Chen dan versi James Martin
DASAR ARTI
Notasi 1 Notasi
2
Kardinalis Kardinalitas satu-ke-
1 1 satu
Kardinalitas satu-ke-
1 M banyak
Kardinalitas banyak-ke-
M banyak
M

11
Kardinalitas Mandatory
1 One
M Kardinalitas Banyak
(1,2,...M)
01 Kardinalitas Optional 0
atau 1
0 Kardinalitas Optional 0
0M atau banyak
(0,1,2,...M)

Relationship
Class-Subclass / Subtipe-Subtipe Relationship Class-
ISA ISA Subclass

Relationship Eksklusip
 Terkadang pula, notasi untuk relasi-relasi yang bukan banyak-ke-banyak ditiadakan
dari Diagram E-R. Cara penggambaran semacam ini sangat dipengaruhi oleh tahap
implemetasi.
8.3.2.1 Contoh kasus kardinalitas relasi film video dengan
menggunakan notasi ERD versi James Martin
Dari gambar 8.4, jelas 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.

Film || Disimpan Sbg 0

Copy_Film

Gambar 8.4 Diagram Kardinalitas Relasi versi James Martin

8.3.2.2 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 di atas, jumlah
maksimumnya adalah ‘banyak’ (suatu nilai tak terdefinisi yang lebih dari satu). Dengan
menggunakan notasi pada kardinalitas relsi versi James Martin di atas, relationship ini
digambarkan sebagai berikut.

Film || Disimpan Sbg 0

Copy_Film

Gambar 8.5 Diagram Kardinalitas maksimum dan minimum

Pada Gambar 8.5 simbol nol pada garis dekat entitas COPY FILM berarti
kardinalitas minimum, sementara notasi berkaki tiga berarti kardinalitas maksimum
banyak. Sudah tentu suatu relationship adalah dua arah (bidirectional) sehingga ada juga
notasi kardinalitas yagn dekat dengan entitas FILM. Perhatikan bahwa minimum dan
maksimum entitas ini keduanya sama, yaitu kardinalitas satu. Hal ini disebut kardinalitas
mandatory one. Dengan kata lain, tiap copy suatu film yang disimpan harus merupakan
satu copy yang tepat dari 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 optimal, sedangkan kardinalitas maksimum adalah satu; partisipasi
adalah mandatory.
Contoh-contoh dari tiga relationship yang menampilkan semua kombinasi
kardinalitas minimum dan maksimum yang mungkin dapat dilihat pada Gambar 8.6 di
bawah ini.

Pasien || Miliki | Riwayat

Penyakit

Gambar 8.6. (a) Diagram Kardinalitas Mandatory

Ditugask
Pegaw an Proyek
ai pada
 Gambar 8.6. (a) Diagram Kardinalitas Satu Optimal, Satu Mandatory

Pegawai Ditugaskan pada

Gambar 8.6. (c) Diagram Kardinalitas Optimal

Dari gambar 8.6 di atas ada tiga deskripsi singkat dari masing-masing kardinalitas, yaitu:
• PASIEN Memiliki RIWAYAT PENYAKIT (Gambar 8.6 (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 8.6 (b)). Tiap PROYEK memiliki
paling sedikit satu PEGAWAI yang dirugaskan 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 Menikah PEGAWAI (Gambar 8.6 (c)). ERD ini adalah kardinalitas nol
atau satu dalam dua 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 sturan ini, angka lima dapat ditempatkan di atas atau di bawah garis
berkaki tiga dekat entitas PROYEK pada Gambar 8.6 (b).

8.2.2.3 Ketergantungan keberadaan (Exitence Dependency)

Konsekuensi dari kardinalitas mandatory one adalah bahwa suatu instance dari tipe
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 suatu entitas tidak akan ad tanpa keberadaan instance dari entitas lain
yang direlasikan.
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 adalah sama. Untuk contoh film video, COPY FILM
adalah entitas lemah.

8.3.2.4 Indentiflying Relationship.

Seperti telah dijelaskan di atas bahwa entitas lemah sering tidak memiliki idenfier
alami (atau kunci kandidat), maka kunci utama dari entitas paBiaya/pemilik (entitas
tempat entitas lemah bergantung) sering digunakan sebagai kunci utama dari entitas anak
(chilod) yagn bergantung. Gambar 8.6 di atas dapat diperbaiki menjadi seperti gambar
8.7.

Nama NoCop
NoFil NoFil
Film y
m m

Film Copy
Film

Gambar 8.7 Diagram Entitas Lemah

Pada Gambar 8.7 tampaklah bahwa kunci utama entitas paBiaya FILM, yaitu
NO_FILM, adalah bagian lain dari kunci utamanya). Suatu Identiflying Relationship
merupakan relationship tempat kunci utama entitas parent digunakan sebagai bagian
kunci utama dari entitas anak.
Ada dua keuntungan dari Identiflying relationship, antara lain sebagai berikut.
• Integritas data. Keuntungan keberadaan dikuatkan karena kunci utama yang dipakai
bersama-sama (oleh sebab itu entitas lemah tidak akan ada kecuali entitas paBiaya
ada).
• Memudahkan pengaksesan entitas anak. Pada contoh di atas, COPY FILM dapat
dicari jika nomor film dan nomor copy diketahui.

8.4 TAHAPAN PEMBUATAN DIAGRAM E-R

Diagram E-R selalu dibuat secara bertahap. Paling tidak ada dua kelompok
pentahapan yagn bias ditempuh di dalam pembuatan Diagram E-R, yaitu:
1. tahap pembuatan Diagram E-R awal (preliminary design)<
2. tahap optimasi Diagram E-R (final design ).
Langkah-langkah teknis yang dapat kita lakukan untuk menghasilkan Diagram E-R
adalah sebagai berikut.
a. Mengidentifikasi dan menetapkan seluruh entitas yagn akan terlibat.
b. Menentukan atribut-atribut key (primary key) dari masing-masing entitas.
c. Mengidentifikasi dan menetapkan seluruh relasi di antara entitas-entitas yang ada
berserta foreign-key-nya (jika terjadi kardinalitas relasi one to many to many).
d. Menentukan derajat/kardinalitas relasi untuk setiap relasi.
e. Melengkapi entitas dan relasi dengan atribut-atribut deskriptif (non-key).
Untuk menetapkan langkah-langkah teknis pada tahap pertama tersebut serta
mewujudkan perancangan basis data pada lingkup sistem perkuliahan, maka urutan
penggambarannya adalah sebagai berikut.

8.4.1 MENGIDENTIFIKASI DAN MENETAPKAN SELURUH

ENTITAS YANG AKAN TERLIBAT
Sebagaimana telah disebutkan, entitas mewakili sebuah kumpulan entitas/individu
yang jelas eksistensinya dan dapat berdiri sendiri. Akan tetapi, entitas mana saja yang
akan kita pilih/libtkan tidak hanya tergantung pada jenis topik/sistem yang kita tinjau,
tetapi juga ditentukan oleh seberapa jauh ruang lingkup yan gingin kita akomodasi dalam
rancangan basis data kita. Dalam lingkup sistem perkuliahan sesungguhnya ada banyak
sekali entitas yagn bisa kita libatkan seperti Mahasiswa, Kuliah, Praktikum, Dosen,
Asisten, Ruang, Jurusan, Literatur dan lain-lain. Namun, dalam lingkup sistem
perkuliahan yagn sederhana sesuai dengan pembahasan di bab sebelumnya, dapat kita
identifikasi adanya tiga buah entitas, yaitu Mahasiswa, Kuliah dan Dosen.

Mahasiswa Kuliah
Dosen

Gambar 8.8 (a) Identifikasi entitas yang terlibat

8.4.2 MENENTUKAN ATRIBUT-ATRIBUT KEY (PRIMARY KEY)

DARI MASING-MASING ENTITAS
Atribut-atribut key yagn kita sertakan di masing-msing entitas merupakan atribut
terpenting yang dapat mengidentifikasi (membedakan) setiap entitas yang ada di
dalamnya. Keberadaan atribut ini juga akan memberi keyakinan tentang kebenaran
eksistensi dari setiap entitas. Salah satu ciri dari entitas adalah kemandiriaannya.
Kemandirian itu terlihat dari kejelasan atribut yang menjadi key dan perbedaannya
dengan key ayng ada di entitas yang lain.

NIM Kd_MK NID

Mahasis Kuliah Dosen

wa
Gambar 8.8 (b) Penentuan primary key
8.4.3 MENGIDENTIFIKASI DAN MENETAPKAN SELURUH RELASI
DI ANTARA ENTITAS-ENTITAS YANG ADA FOREIGN-KEY-
NYA
Langkah ketiga ini merupakan langkah terpenting dalam pembentukan Diagram E-R.
Ketepatan kita dalam menentukan relasi-relasi yang terjadi di antara entitas akan sangat
menetukan kualitas rancangan basis data yang kita bangun. Relasi-relasi yang kita
tetapkan harus dapat mengakomodasi semua fakta yang ada, dan menjamin semua
kebutuhan penyajian data, tetapi di sisi lain juga harus dibuat seoptimal mungkin agar
tidak memakan ruang penyimpanan data. Untuk itulah, relasi-relasi yang sifatnya tidak
langsung harus ditiadakan.
NI NI Kd_ Kd_ NI NI
M M MK Kd_ MK D D
MK

Bel Aja
Mahasis ajar Kulia r Dos
wa h en

Gambar 8.8 (c) Identifikasi seluruh relasi dan foreign-key-nya

Relasi Belajar akan dapat mengakomodasi adanya fakta tentang sejumlah mahasiswa
yang mengambil mata kuliah tertentu dan sebaliknya sejumlah mata kuliah yang diambil /
dipelajari oleh mahasiswa tertentu. Demikian juga dengan relasi Ajar yang dapat
mengakomodasikan fakta tentang dosen yang mengajar mata kuliah tertentu. Kendati
dalam bahasa alamiah, ada kebutuhan untuk menyajikan informasi tentang mahasiswa
mana saja yang diajar oleh seorang dosen. Karena kebutuhan penyajian informasi
semacam iti telah dapat dipenuhi dengan melakukan query yang melibatkan entitas kuliah
dan kedua relasi yang telah ada.

8.4.4 MENENTUKAN DERAJAT / KARDINALITAS RELASI

UNTUK SETIAP RELASI
Karena memang fakta memperlihatkan bahwa seorang mahasiswa boleh mengambil
beberapa mata kuliah sekaligus dan begitu sebaliknya, sebuah mata kuliah dapat diikuti
oleh banyak mahasiswa sekaligus, maka derajat relasi antara entitas Mahasiswa dan
Kuliah adalah banyak-ke-banyak.
Kd_
NI NI Kd_ MK NI NI
M MK Kd_ D D
M MK

Mahasis Bel Aja

ajar  Kulia  r Dos
wa h en

Gambar 8.8(D-3) Penentuan derajat kardinalitas relasi

8.4.5 MELENGKAPI ENTITAS DAN RELASI DENGAN ATRIBUT-
ATRIBUT DESKRIPTIF (NON-KEY)
Berangkat dari fakta yang ada, atribut-atribut deskriptif yang dapat kita sertakan
pada masing-masing entitas danrelasi. Keberadaan atribut-atribut deskriptif ini
merupakan refleksi pengakomodasian terhadap fakta yang memang ada, dan kebutuhan
penyajian data pada saat yang lain. Atribut deskriptif ini juga tidak banyak berperan
dalam membentuk pemahaman kita dalam “membaca” sebuah Diagram E-R, bahkan
cenderung mengganggu, karena biasanya jumlah atribut demikian cukup banyak. Karena
itu, khususnya pada sebuah sistem yang besar dan kompleks, langkah terakhir ini sering
kali tidak dilakukan sehingga Diagram E-R sampai pada langkah ke empat saja.

8.5 DIAGRAM E-R DENGAN KAMUS DATA

Tujuan utama pembuatan Diagram E-R adalah untuk menunjukkan objek-objek
(entitas) apa saja yang ingin dilibatkan dalam sebuah basis data dan bagaimana hubungan
yang terjadi di antara objek tersebut.
Dalam hal ini diperbolehkan untuk menggambarkan Diagram E-R dengan tambahan
Kamus Data.
Belaj
N N Ajar N
Mahasis ar Kuliah Dosen
wa 1

Gambar 8.9 Diagram ER lengkap dengan kardinalitas relasi

Kamus Data:
Mahasiswa = { NIM, Nama_Mhs, Alamat, Tpt_lahir, Tgl_lhr }
Kuliah = { Kode MK, Nama_MK, SKS, Semester }
Dosen = { NID, Nama_Dos, Keahlian, Alamat }
Mempelajari = { NIM, Kode MK, Index_Prestasi }
Mengajar = { Kode MK, NID, Waktu, Ruang }

8.6 MODEL DATA LANJUT

8.6.1 VARIAN ENTITAS
Idealnya, entitas yang kita libatkan dalam sebuah diagram E-R adalah entitas kuat /
bebas (strong entitas). Entitas demikian tidak mempunyai ketergantungan dengan entitas
lainnya.
Namun demikian, dalam pembuatan diagram E-R kita tidak selalu dapat melibatkan
entitas seperti itu. Adakalanya juga melibatkan entitas yang lemah (Weak entity sets) atau
bagian dari entitas lainnya.

8.6.2 ENTITAS LEMAH

Entitas ini berisi entitas-entitas yang kemunculannya tergantung pada eksistensinya
dalam sebuah relasi terhadap entitas lainnya. Entitas yang demikian memiliki atribut yang

Nam
a_
Ortu
dapat berfungsi sebagai key, yang benara-benar dapat menjamin keunikan entitas di
dalamnya.
Ni
Ni m Nam
Contoh: m
Na a_
ma Ortu Alm
Mem Orang_T
Mh iliki ua _
s Ni Ort
Alm m Hob
Mahasis u
_ by
Mh Ho
s Tg Men by
l_ ye- Hob
lhr nan
gi y

Gambar 8.10 Diagram Weak Entity yang lebih kompleks

8.6.3 SUB ENTITAS (SUB TIPE ENTITAS)

Sub entitas merupakan entitas yang beranggotakan entitas-entitas yang merupakan
bagian dari himpunan entitas yang lebih superior. Sub entitas merupakan hasil
dekomposisi himpunan entitas berdasarkan pengelompokan tertentu.

Contoh:
NID NID

Dosen

IS
A

Nama_K
Pang an
kat
Ni Dosen_Tet Dosen
k ap tidak_Tetap

Tgl_M
sk Alm_
Kan
Gambar 8.11 Diagram Sub Tipe Entity
8.6.4 RELASI MULTI ENTITAS
Relasi multi entitas (N-ary relasi) merupakan relasi dari tiga himpunan entitas atau
lebih.

Contoh:
 Pada sistem perkuliahan kita dapat menambahkan himounan entitas baru, yaitu
himpunan entitas ruang yang kemudian bersama dengan himpunan etitas dosen dan
kuliah membentuk relasi ‘pengajaran’.

Kode_ Nama_
Kode_ kul Nama_ dos
kul dos

Pen
Kuliah g- Dosen
ajar
an

Kode_ru Wakt
ang u

Ruang

Kode_ru Kapasita
ang Nama_ru s
ang
Gambar 8.12 Diagram ER Multi entitas

Pada diagram E-R di atas, entitas ruang dibentuk karena data ruang juga memiliki
entitas-entitas dengan jumlah atribut khusus (kode_ruang, nama_ruang, dan kapasitas),
selanjutnya relasi yang kemudian terbentuk dari ketiga entitas di atas tentu saja karena
memiliki key yang berasal dari ketiganya yaitu (kode_kul dari entitas kuliah, nama_dos
dari entitas dosen dan kode_ruang dari entitas ruang). Yang menjadi tidak jelas pada
relasi demikian adalah derajat relasinya.

8.6.5 RELASI GANDA (REDUNDANT RELASI)

Relasi ganda (Redundant relasi) adalah relasi yang muncul antara dua entitas tidak
hanya satu relasi, tapi ada lebih dari satu relasi.

Contoh:

NID Kd_MK

Aj
ar
 Dosen Temp Wakt
Kuliah
at u

kua
sai

NID Kd_MK

Gambar 8.13 Diagram Relasi Ganda

8.6.6 SPESIALISASI DAN GENERALISASI

Jika kita memulai dari sebuah entitas lalu kemudian melakukan pengelompokan yang
melahirkan entitas baru maka kita sedang melakukan Spesialisasi.
Pendekatan bersifat bottom-up, mula-mula terpisah tapi kemudian menjadi satu
proses ini disebut Generalisasi. Dengan demikian, Spesialisasi dan Generalisasi
merupakam dua proses yang berlawanan. Yang ditekankan pada spesialisasi adalah
perbedaan antar kelompok entitas sedang dalam generalisasi yang ditekenkan adalah
persamaannya.
Spesialisasi dan Generalisasi diwujudkan dalam notasi relasi yang khusus yang
disebut Relasi “I S A” sebagai berikut.

Dosen

ISA

Dosen tetap Dosen tdk

tetap

Mahasiswa
 ISA

Mahasiswa D3 Mahasiswa S1

Gambar 8.14 Diagram Relasi ISA

8.6.7 AGREGASI
Agregasi menggambarkan sebuah relasi yang secara langsung menghubungkan
sebuah entitas dengan sebuah relasi dalam diagram E-R.

Mahasiswa Belaja Kuliah

r

Kd_
NIM
MK

Ajar

Kode_Pr
a
Nilai

Kuliah

Kode_Pr Juml_ja
a Nama_P m
ra
Gambar 8.15 Diagram Agregasi
8.7 TRANSDORMASI DIAGRAM E-R KE LRS
(LOGIKAL RECORD STRUCTURE)
Aturan-aturan dalam melakukan transformasi E-R Diagram ke logical record structur
adalah sebagai berikut.
1. Setiap entity akan diubah kebentuk sebuah kotak dengan nama entity berada di luar
kotak dan atribut berada di dalam kotak.
2. Sebuah relasi kadang disatukan dalam sebuah kotak bersama entity, kadang dipisah
dalam sebuah kotak tersendiri.

Aturan pokok di atas akan sangat dipengaruhi oleh elemen yang menjadi titik
perhatian utama pada langkah transformasi, yaitu cardinality/kardinalitas.
8.7.2 1:1 (ONE TO ONE)
Pada kardinalitas one to one, sebaiknya panah diarahkan ke entity dengan jumlah
atribut yang lebih sedikit.

Misalkan: Terdapat suatu relasi KAWIN yaitu penggabungan antara entity SUAMI
dengan entity ISTRI.3
Pda kasus ini symbol ‘@’ yang diletakkan disalah satu atribut melambangkan primary
key pada entitas tersebut., sedangkan atribut yang tidak memiliki / diberikan symbol ‘@’,
merupakan atribut non-key dari entitas tersebut.
− Penggabungan relasi KAWIN ke entity ISTRI

@NO-SURAT NIKAH @NO-SURAT

SUAMI NO.KTP-S NIKAH
NAMA-S NO.KTP-S SUAMI
TPT-L-S NAMA-S
TGL-L-S TPT-L-S

Ka
win
@NO-SURAT NIKAH @NO-SURAT
NO.KTP-I NIKAH ISTRI
NAMA-I NO.KTP-I
TPT-L-I NAMA-I
ISTRI TGL-L-I TPT-L-I
TGL-KAWIN TGL-L-I
TGL-KAWIN

Gambar 8.16 (a) Diagram ER One to One ke LRS

− Penggabungan relasi KAWIN ke entity SUAMI

@NO-SURAT
@NO-SURAT NIKAH
NIKAH
SUAMI NO.KTP-S NO.KTP-I
NAMA-S NAMA-I SUAMI
TPT-L-S TPT-L-I
TGL-L-S TGL-L-I
TGL-KAWIN
Ka
win

@NO-SURAT NIKAH
@NO-SURAT
NIKAH
NO.KTP-I
NAMA-I
TPT-L-I
 NO.KTP-I ISTRI
NAMA-I
TPT-L-I
ISTRI TGL-L-I
TGL-KAWIN

Gambar 8.16 (b) Transformasi Diagram ER One to One LRS

8.7.3 1: M (one to many)

Pada kardinalitas relasi one to many, maka relasi harus digabungkan dengan entity
pada pihak yang many, dan tidak perlu melihat banyak sedikitnya atribut pada entity
tersebut.
Misalkan terdapat relasi KERJA yang merupakan penggabungan antara entity
PEGAWAI DAN PROYEK. Relasi tersebut akan dikonversikan ke LRS dan
digabungkan ke entity PEGAWAI, karena entity PEGAWAI memiliki kardinalitas relasi
Many.

@NO_PEG
PEGAWAI @NO_PEG @ PEGAWAI
NAMA @KD_PROY
NAMA

KERJA

@KD_PROY
@KD_PROY TGL_MULAI PROYEK
PROYEK BIAYA
TGL_MULAI
BIAYA

Gambar 8.17 Transformasi Diagram ER One to Many ke LRS

Pada kasus di atas symbol ‘@’ yang diletakkan disalah satu atribut melambangkan
primary key pada entitas tersebut, dan symbol ‘@@ ‘ yang diletakkan disalah satu atribut
melambangkan foreign key, sedangkan atribut yabg tidak memiliki / diberikan symbol
‘@’, merupakan atribut non-key dari entitas tersebut. Pada gambar 8.17 di atas terlihat
bahwa entitas PEGAWAI memiliki foreign key ‘Kd_Proy’ yang berasal dari entitas
PROYEK.

8.7.4 M: N (MANY TO MANY)

Pada kardinalitas Many to Many, maka relationship berubah status menjadi file
konektor (yang akan merubah kardinalitas many to many seolah-olah menjadi one to
many), sehingga baik entity maupun relasi akan menjadi struktur record tersendiri.
Dengan demikian, maka panah dari entity a dan entity b mengarah ke relationship
tersebut.
Misalkan terdapat relasi BELI yang merupakan penggabungan antara entity
PELANGGAN dengan entity pada BARANG. Relasi tersebut bila dikonversikasikan ke
LRS akan menjadi seperti gambar berikut.
@KD_PEL
PELANGGAN @KD_PEL
NAMA
PELANGGAN
NAMA

@
@ @[ @KD_PEL] @[ @KD_BRG
BELI @ @ @[ @KD_BRG]
BELI
JUMLAH

@KD_BRG @KD_BRG
PROYEK
BARANG NAMA_BRG
NAMA_BRG HARGA_BRG
HARGA_BRG

Gambar 8.18 Transformasi Diagram ER Many to Many ke LRS

Pada kasus di atas symbol ‘@ ‘ yang diletakkan di salah satu atribut melambangkan
primary key pada entitas tersebut dan symbol ‘@@’ yang diletakkan di salah satu atribut
melambangkan foreign key, sedangkan atribut yang tidak memiliki / diberikan symbol
‘@’, merupakan atribut non-key dari entitas tersebut.
Pada gambar 8.18 di atas terlihat bahwa relationship BELI berubah menjadi file
konektor dengan tiga atribut, yakni @@[@KD_PEL], yang merupakan foreign key bagi
entitas PELANGGAN, dan @@[@KD_BRG] yang merupakan foreign key bagi entitas
BARANG sehingga keduanya diberi symbol ‘@@’.

Sementara @KD_PEL, dan @KD_BRG merupakan primary key bagi entitas BELI,
sehingga kedua atribut tersebut diberi symbol ‘@’ yang menunjukkan fungsi sebagai
primary key.
Sedangkan atribut JUMLAH pada entitas BELI merupakan atribut deskriptif non key.

8.8 TRANSFORMASI ERD ATAU LRS KE RELASI

Subbab ini akan membahas bagaimana ERD /LRS di transformasikan ke relasi.
Transformasi ini sering disebut dengan mapping ERD ke database relational.
Transformasi ini dibagi ke dalam dua langkah, yaitu transformasi dengan
merepresentasikan relationship menjadi relasi-relasi yang atau tabel-tabel database.
Relasi-relasi yang berasal dari transformasi ini dapat dinormalisasikan dengan tekni-
teknik normalisasi.
8.8.1 MEREPRESENTASIKAN ENTITAS
Tiap tipe entitas dalam ERD ditransformasikan menjadi suatu relasi. Kunci utama
/primary key (Identifier) tiap entitas menjadi kunci utama /primary key dari relasi yang
bersangkutan. Adapun karakteristik yang perlu diperhatikan dalam memastikan atau
memilih satu atau beberapa atribut dari kunci kandidat / candidate key telah dibahas pada
bab sebelumnya (BAB I ‘PENGANTAR SISTEM BASIS DATA’. 6. ‘Kunci Elemen
Data’. c. ‘Primary Key’)
Tiap atribut bukan kunci dari tipe entitas menjadi atribut bukan kunci relasi. Relasi-
relasi yang dibentuk dari tipe entitas mungkin dimodifikasi sebagai relation yang
dipresentasikan, seperti yang telah dibahas pada kasus TRANSFORMASI ERD ke LRS
di atas .
Gambar 8.19 (a) menunjukkan representasi dari tipe entitas PELANGGAN suatu
perusahaan. Relasi PELANGGAN yang berkaitan dengan entitas PELANGGAN dapat
dipresentasikan sebagai berikut.

PELANGGAN (NO.PELANGGAN →
NAMA,ALAMAT, KOTAKKODEPOS,POTONGAN)

Relasi di bawah ini jika dipresentasikan sebagai tabel dengan data sample pada Gambar
8.19 (a) akan menjadi Relasi / Tabel Pelanggan seperti terlihat pada gambar 8.19 (b).

Kota

Alamat
KodePos

Nama
Discount
NoPelang Pelanggan
gan

(a) ERD
pelanggan
No_Pelan Nama Alamat Kota Kode Disco
ggan Pos unt
A1273 Toko Jl.RST No.3 Solo 20122 5%
ABC
A6390 PT.Jali JL. XAB Jakart 14440 3%
 No.12 a
..........

(b) Relasi

Gambar 8.19 Transformasi Suatu Tipe Entitas menjadi Relasi

8.8.2 MEMPRESENTASIKAN RELATIONSHIP

Prosedur untuk mempresentasikan relationship tergantung kepada derajat relationship
(unary, binary, atau ternary), serta karakteristik relationship.

8.8.2.1 Relationship binary satu-ke-banyak (1:N)

Relationship binary satu-ke-banyak (1:N) dalam ERD dipresentasikan dengan
menambah satu atau lebih atribut primary key entitas yang berbeda di sisi satu (1) sebagai
foreign key dlam relasi yang ada pada sisi banyak (M).
Gambar 8.20 menunjukkan suatu contoh aturan ini. Gambar 8.20 (a) menunjukkan
relationship (1:M) Memberikan yang menghubungkan PELANGGAN dan PESANAN.
Dua relasi, PELANGGAN dan PESANAN, dibentuk dari tipe masing-masing entitas.
NO.PELANGGAN yang merupakan primary key pada tabel /relasi PELANGGAN (pada
sisi satu dari relationship) ditambahkan sebagai foreign key tabel /relasi PESANAN
(pada sisi banyak dari relationship).

No_Pelang Nam TglPesa

gan a Alam nan
at
No_Pelang
Ko gan TglKiri
ta m

KodePos Beri
Pelanggan Pelanggan

Discou
nt
(a) ERD dengan Kardinalitas Relasi 1 : M

Pelanggan
No_Pelan Nama Alamat Kota Kode Disco
ggan Pos unt
A1273 Toko Jl.RST No.3 Solo 20122 5%
ABC
A6390 PT.Jali JL. XAB Jakart 14440 3%
No.12 a
..........

Pesanan
 No_Pesan TglPesa TglKirim No
an nan Pelanggan
57192 12/04/95 19/04/95 A1273
60723 21/05/95 28/05/95 A6390
70112 07/08/95 14/08/95 A1273

(b) Relasi Pelanggan dan Pesanan

Gambar 8.20 Mempresentasikan Relastionship 1:M

Kasus khusus dari aturan di atas beraplikasi pada relationship satu-ke-satu (1:1)
anatra dua entitas A dan B. Pada kasus ini, relationship dapat dipresentasikan dengan
salah satu cara di antaranya sebagai berikut.
 Menambahkan primary key A sabagai foreign key B.
 Menambahkan primary key B sebagai foreign key A.
 Kedua aturan di atas digabungkan.

8.8.2.2 Relationship Binary M:N (Banyak ke Banyak)

Misalkan ada relationship banyak-ke-banyak (M:N) antara dua tipe entitas. A dan B,
untuk relationship seperti ini, perlu dibentuk relasi baru yang terpisah dari kedua entitas
di atas. Primary key dari relasi ini adalah kunci komposisi (kunci gabungan) yang terdiri
dari primary key pada masing-masing entitas dalam relationship. Atribut-atribut bukan
kunci yang bekaitan dengan relationship M:N ditempatkan pada relasi C.
Gambar 8.21 menunjukkan suatu contoh aturan ini. Gambar 8.21 (a) menampilkan
relationship (M:N). Relationship MINTA yang menghubungkan dua tipe entitas
PESANAN dan PRODUK. Gambar 8.21 (b) menunjukkan tipe relasi (PESANAN,
PRODUK dan JENIS PESANAN) yang dibentuk dari tipe-tipe entitas dan relationship
Minta.
Langkah pertama untuk melakukan pembentukan ketiga relasi ini adalah suatu relasi
dibentuk untuk tipe-tipe entitas dalam relationship (yaitu PESANAN, dan PRODUK),
kemudian pembentukan relasi baru untuk relationship Minta (yang disebut JENIS
PESANAN), dilaksanakan. Primary key JENIS PESANAN adalah kata kunci kombinasi
antara primary key PESANAN dan PRODUK. Atribut bukan kunci JUMLAH
PESANAN juga muncul pada entitas JENIS PESANAN.
TglPesa
NoPesa nan TglPesa
nan nan

Pesanan

0
Min Atubut
ta lainnya

___
NoProdu
k Produk
 Keteran Ruan
gan g
(a) ERD

Pesanan
No TglPesana TglKirim
Pesanan n
57192 12/04/95 19/04/95
60723 21/05/95 28/05/95
70112 07/08/95 14/08/95

Jenis Pesanan (berasal dari relationship Minta)

No No Jml
Pesanan Produk Pesanan
60723 M120 3
60723 B261 4

Produk
No Keteran Ruang Antribut
Produk gan lainnya
M120 Tas G001 ................
B261 Karpet G002 ................
F145 Lemari F005 ................

(b) Relasi

Gambar 8.21 Merepresentasikan Relationship M:N

8.9 APLIKASI ERD

8.9.1 THREE-TIERS CLIENT SERVER
Arsitektur three-tiered merupakan salah satu trend penting pada perkembangan
aplikasi corporate. Konsep three tier ini merupakan suatu konsep yang menarik dan
menjadi kenyataan pada pasar perangkat lunak di masa kini dan masa mendAgus.

Perbedaan Arsitektur three-tiered dan two-tiered

Arsitektur two-tiered adalah lingkungan client server traditional. Pada arsitektur ini
suatu aplikasi dibagi menjadi dua entitas antara lain.
• Client atau front end, yang merupakan bagian user inteface
• Server atau back end, yang mengelola database, lazim disebut database server

Dalam konfigurasi yang tipikal, pembagian ini juga meliputi pembagian hardware
dan software. Client biasanya terletak pada workstation yang digunakan oleh user,
dan dibuat dengan menggunakan program seperti PowerBuilder, SqlWindows, Visual
Basic, atau Delphi. Sedangkan server adalah suatu komputer server yang diletakkan
di bagian lain pada jaringan yang menjalankan perangkat lunak database software,
seperti Sybase, atau Oracle, Arsitektur ini ditampilkan pada Gambar 8.22

Cli Serv
ent er

Front End Back End

User Interface
Database Management

Gambar 8.22 arsitektur client server two-tiered

Arsitektur three-tier menambahkan komponen ketiga seperti pada Gambar 8.23

Pada middle-tier, adalah bussiness process server, merupakan suatu bagian perangkat
lunak terpisah, biasanya dijalankan pada hardware yang terpisah. Bagian ini
menjalankan program yang berisi aturan-aturan aplikasi, seperti menerapkan aturan
bisnis dan melakukan pemrosesan yang kompleks. Dari sisi pandang client, business
process server adalah berfungsi sebagai server.
Dari sisi pandang databse server, business process server dianggap sebagai client.
Suatu business process server dapat berupa suatu mesin UNIX yang menjalankan
program hitungan yang kompleks.

Bussine
Cli ss Serv
ent Process er
Server
Front End Middle Tier Back
End
User Interface Business Rules
Database Management
Application Logic

Gambar 8.23 Arsitektur client-serve three-tiered

Yang harus diperhatikan adalah konsep middle-tier tidak sama dengan

middleware. Middleware adalah perangkat lunak yang menghubungkan program
yang berjalan pada plaform yang berbeda, middleware ini ditujukan agar program
yang berjalan pada plaform yang berbeda tersebut dapat saling mengirimkan message
dan data. Middleware memainkan peranan yang penting pada arsitektur three-tier,
karena meddlewared inilah yang menghubungkan ketiga tier tersebut.
Misalkan suatu sistem client server yang bekerja sebagai suatu sistem penerimaan
order. Program client akan memasukkan setiap adanya order penjualan yang baru.
Order ini dikirim ke middle-tier, lalu di middle-tier order akan diproses. Misalkan
 akan diperiksa apakah barang yang dipesan tersebut tersedia di inventory,
menghitung discount yang akan diberikan, mengecek jumlah tunggakan pelanggan
tersebut, dan lain-lainnya. Bila order tersebut bisa diterima, maka middle-tier akan
mengirimkan pesan menyetujui ke client, dan juga mengirimkan data baru yang berisi
order baru ini ke database server, untuk menyimpan order tersebut.
Pada system two-tier, aturan bisnis diterapkan pada program front end atau dapat
juga database server (merupakan mekanisme penyimpanan-stored procedure).
Dengan cara ini pada model two-tired, system akan lambat bila proses yang harus
dilakukan adalah besar. Sehingga keuntungan utama dari model three-tired adalah:
meringankan beban database server dengan cara memebagi pekerjaan ke business
process server.
Sebenarnya konsep arsitektur ini tidaklah benar-benar baru, yang hanya baru
adalah metode mempartisinya secara formal sehingga tersedia perangkat Bantu yang
dapat digunakan untuk menyusun model ini. Di lain pihak model three-tired ini
biasanya hanya cocok untuk proyek-proyek yang berukuran besar. Untuk aplikasi
kecil atau menengah, mungkin one atau two-tired lebih tepat.

8.9.2 ARSITEKTUR MANY-TIERED

Untuk pengembangan lebih lanjut, kini dikembangkan arsitektur many-tiered.
Aplikasi didistribusian ke lebih dari tiga plaform, yang biasanya dilakukan dengan
membagi proses bisnis tersebut, dapat juga disebut fourth-tier.
Ada juga variasi yang bertujuan sebagai suatu penyederhanaan. Pembagian ketiga
tier ini dapat juga tidak dilakukan secara fisik diletakkan di tiga system computer terpisah
yang saling dihubungkan. Akan tetapi diletakkan pada satu atau dua computer saja. Yang
penting adalah aplikasi-aplikasi tersebut tersegmentasi secara logis dan tidak tergantung,
tetapi dapat saling berkomunikasi dan bertukar message dan data.

Keuntungan

Banyak keuntungan dari model three-tieredni diantaranya yang terpenting adalah

peningkatan unjuk kerja atau performance. Dengan kata lain dapat dikatakan model ini
mampu menyediakan satu solusi Graphical User Interface (GUI) yang user friendly pada
suatu computer desk top client, yang mengemas proses suatu transaksi berukuran amat
sangat besar yang biasanya hanya diperoleh dan ditemukan pada computer mainframe.
Hal ini memecah kebutuhan untuk menyediakan suatu sistem pemrosesan besar dengan
GUI yang memeiliki 40 sampai dengan 50 user.
Hal lainnya adalah secalability. Arsitektur ini dapat dengan cepat dan mudah
menaikkan jumlah transaksi pengguna tanpa perlu perubahan besar pada investasi
hardware dan software. Misalkan pada suatu client server yang two-tiered yang
meletakkan prosedur penyimpanan order pada database server. Ketika volume transaksi
membesar, database server menjadi pelan. Untuk itu menaikkan unjuk kerja kembali,
maka pilihan untuk penambahan database server sulit untuk dilakukan.
Pada sistem three-tiered, masalah ini dengan mudah dapat dipecahkan, yaitu dengan
cara menambahkan middle-tier server. Setiap server menjalankan program business
server yang sama. Tidak menjadi masalah client mana yang dilayani, karena setiap client
dapat melakukan dengan koneksi server yang manapun, ketika yang satunya sibuk.
 Cli
ent

Back End

Cli Management
Database Stored
ent Database
Procedures
Server

Cli
ent

Gambar 8.24 Stored Procedures pada Database Server

Bussine
Cli
ss
ent
Process
Server

Cli
ent
Bussine
ss
Process Databas
Cli Server e Server
ent

Gambar 8.25 Penambahan Middle-tier untuk menaikkan performa

Suatu aplikasi three-tier juga mudah untuk pindah ke berbagai back-end server.
Pada aplikasi two-tier, misalnya ingin mengubah dari SQL Server ke Oracle, atau DB2,
maka seluruh prosedur store harus ditulis ulang, karena sangat bergantung pada dialek
dari tiap produk SQL tersebut. Pada arsitektur three-tiered, penggunaan prosedure store
ini diminimalkan karena proses logik dilaukan di middle-tier.
Misalkan pada model client server two-tier yang lain proses aturan bisnis diletakkan
di program client. Hal ini memiliki potensi untuk menimbulkan problem juga.
Permasalahan perawatan adalah problem yang terbesar. Bagaimana untuk melakukan up
nilai pada beratus-ratus client, dengan pemrograman aturan bisnis yang baru. Hal lainnya
adalah biaya upgrade untuk tiap workstation sehingga proses dapat berlangsung dengan
cepat, karena tiap workstation tersebut harus menjalankan program yang melakukan
proses aturan bisnis tersebut juga. Arsitektur three-tiered memecahkan masalah ini,
karena pengubahan aturan bisnis hanya perlu dilakukan di middle server saja sehingga
mudah untuk dilakukan perawatan perangkat lunak.

GUI SP Back End

Client Database
Management Databa
se
Server
GUI SP
Client

GUI : Graphical User Interface

GUI SP SP : Stored Precedures
Client

Gambar 8.26 Arsitektur Two-tiered dengan stored procedures pada client

Suatu kemampuan yang berharga dari arsitektur three-tier ini adalah kemampuan
untuk
mendukung berbagai platform client yang berfungsi sebagai front-end. Fort Software Inc,
telah mengembangkan suatu system yang memiliki client dari MacIntosh, Windows, dan
Unix Motif, keseluruhannya dikoneksikan ke mesin yang sama.

8.9.3 CLIENT DAN SERVER YANG KHUSUS

Suatu indikasi dari flexibilitas dari arsitektur three-tiered ini adalah kenyataan
bahwa client dan database server tidak harus merupakan suatu perangkat computer yang
biasa dibayangkan.
Client tidaklah harus merupakan suatu workstation. Pengguna dapat menjaloankan
aplikasi dari Macintosh, atau dari tombol tekan pesawat telefon, ataupun dari Automated
Teller Machine (ATM). Kesemuanya dikoneksikan kepada business prosess server yang
sama, dan menjalankan suatu kumpulan aturan bisnis yang sama.
Begitu juga dengan database server dapat berupa sesuatu yang bukan produk SQL.
Sebab business prosess layer menyajikan pada client dengan suatu pandangan logis
terhadap data, menghalangi akses langsung client dari dan ke database server. Back end
server dapat berupa IMS, VSM atau suatu sumber data yang real time. Bentuk
penyimpanan data pada back end server ini tidak memberikan pengaruh pada proses
bisnis. Pada terapannya, trend yang ada pada saat ini adalah menggunakan three-tier
sebagai suatu front-end untuk system non-relasial, misal legacy mainframe system.

8.9.4 PROGRAM PENGEMBANG ARSITEKTUR THREE-TIERS

Ada dua pendekatan utama dalam memilih alat bantu program pengembangan ini
seperti berikut.
• Pendekatan satu sumber (single vendor), dengan menggunakan suatu produk
tunggal, misal Forte atau Dynasty. Produk-produk ini mampu mengembangkan client,
middle-tier, dan pemanggilan ke database server, serta mengelola koneksi dan
komunikasi antar ketiga tier tersebut.
• Pendekatan mix and match, dengan cara mengambil berbagai produk dengan
vendor yang berbeda dengan melakukan pilihan yang tepat. Dan mengkonfigurasikan
sehingga produk-produk tersebut dapat saling komunikasi.

Permasalahan dengan satu sumber adalah satu solusi yang bersifat proprietary dan
tidak terlalu “open”. Sehingga dengan menggunakan pendekatan mix and match
ketergantungan kepada vendor tunggal menjadi berkurang atau tidak ada sama sekali.
Kekurangan dari pendekatan mix and match adalah dibutuhkannya kemampuan dan
pengetahuan yang luas bagi developer, misal pemrograman C level rendah. Juga
berkurangnya flexibilitas dalam mempartisi aplikasi.

SUMBER TUNGGAL
Produk ini menyediakan lingkungan pengembangan yang konprehensif dan
terintegrasi, untuk suatu aplikasi three-tiered. Keseluruhan proses seperti diesain user
interface, pemrograman proses bisnis, pengaksesan database, dan komunikasi antar tier.
Setiap produk memiliki feature yang hampir sama, antara lain sebagi berikut.
• Kemampuan mengembangkan aplikasi pada satu platform dan memindahkan ke
mesin lainnya.
• Disain screen yang interaktif.
• Bahasa pemrograman yang proprietary dengan embedded SQL.
• Mendukung berbagai platform untuk client dan middle-tier.
• Koneksi pada produk database server terkemuka.

Forte dan Dynasty menyediakan perangkat bantu grafis untuk “partitioning”.

Partitioning adalah proses membagi aplikasi kedalam objek-objek, dan menempatkan
objek tersebut pada berbagai tier dan platform. Dengan menggunakan perangkat Bantu
partitioning, dapat dispesifikasikan, apakah suatu objek ditempatkan pada client, atau
middle-tier, system operasi apakah yang digunakan, dan untuk objek di middle-tier, target
server. Perangkat Bantu partitioning kemudian akan menghasilkan kode C atau C++
untuk mesin target. Kemudian kode ini dipindahkan ke mesin target, dikompile, dan di
link. Tetapi produk ini membutuhkan site-license untuk pengembang aplikasi.

8.9.4.1 Forte Software Inc

 Dalam pengembangan program ditest dalam modus interpreter, dan setelah itu
diterjemahkan ke C++, dikompile dan dilink suatu modul runtime dibutuhkan untuk
menjalankan aplikasi. Pemrograman adalah berorientasi objek dan event driven.
Termasuk kemampuan untuk mendefinisikan event. Ini menjadikan suatu business
prosess server, untuk mengirimkan suatu event mengenai suatu kondisi bisnis yang
dideteksi oleh client dan segera meresponsenya.
Untuk runtime ada beberapa perangkat bantu monitoring. Misalnya untuk memonitor
beban pekerjaan dan keluaran business prosess server, juga untuk membuat Bahasa
Alamiine dan offline secara real time. Forte mendukung Windows, Macintosh, Motif
untuk client, berbagai UNIX dan DEC untuk middle tier, dan Orase, Sybase, RDB, dan
DB2/6000 untuk database server.

8.9.4.2 Dynasty Technologies Inc

Dynasty Development Environment menyediakan suatu lay-out yang cepat dengan
perangkat Bantu pendisain layar ala RAD (Rapid Application Development). Bahasa
pemrograman adalah Objek Oriented. Satu aplikasi akan ditranslasikan ke C dan
dikompilasi selama testing, begitu juga ketika akan disebarkan pada server.
Client dari Dynasty dapat bekerja di Windows, Macintosh, Motif, OS/2 Presentation
Manager, dan OpeBahasa Alamiook. Middle tier dapat bekerja di platform DOS, OS/2,
Mac, UNIX, Netware, dan jaringan Windows-compatible lainnya. Database server dapat
berupa Oracle, Sybase, Microsoft SQL Server, SQLBase, atau lainnya melalui ODBC
(Open Database Connectivity).

8.9.4.3 Seer Technology Inc

STI menyediakan perangkat Bantu disain secara grafis, seperti Entity Relationship
(ER) diagram, database diagram, dan menghasilkan aplikasi langsung dari diagram
tersebut. Pemrograman yang dilakukan berbasiskan objek.
Teknologi ini mendukung berbagai platform untuk client: Windows, OS / 2, AIX, Sun
UNIX. Middle tier adalah OS / 2, Windows NT, dan berbagai versi UNIX. Mendukung
konektivitas ke mainframe legacy system seperti CICS, IMS, dan DB2. Database server
lainnya yang didukung adalah: Oracle, Sybase, Informix, dan Microsoft SQL Server.

8.9.4.4 Progress Software corporation

PSC merupakan perangkat Bantu termurah, Client yang didukung adalah Windows
NT, UNIX, VMS, Motif, juga sebagai middle-tier. Middle-tier lainnya yang juga
didukung adalah: AS / 400, OS / 2, atau BAHASAALAMIM. Untuk database server
yang didukung: PROGRESS database, Oracle, Sybase, SQLServer, DB2 / 400, RDB,
RMS, dan ODBC.

8.9.4.5 Produk-produk mix and match

Pada pendekatan ini digunakan produk-produk dari vendor yang digunakan sebagai
komponen pembentuk struktur three-tier. Suatu masalah penting dalam
mengkombinasiakn produk seperti ini adalah pengguna middleware yang akan
menyatukan program-program tersebut bersama. Beberapa protocol standar yang telah
berkembang dan digunakan untuk menggabungkan berbagai produk untuk arsitektur
three-tier ini.
• Remote Procedures Call (RPC) - suatu teknik yang digunakan untuk suatu program
di suatu platform untuk memanggil suatu prosedur yang berada di platform lainnya.
Seperti halnya memanggil prosedur yang ada di library lokal. RPC merupakan istilah
generik, memiliki berbagai implementasi yang berbeda.
• Common Object Request Broker Architecture (CORBA)
- Disusun oleh Objek Management Group (OMG). Suatu standard untuk
menyebarkan objek pada berbagai platform, dan mendukung pengiriman message
anatra objek tersebut.
• Distributed Computing Environment (DCE) - Disusun oleh Open system
Foundation (OSF). Suatu standar mengirimkan data dan message antara platform.
DCE menggunakan kemampuan RPC, dan suatu directory service, dan security dan
banyak hal yang lainnya.

8.9.4.6 JYACC Inc

Sistem pengembang JAM menyediakan JAM / TPi untuk aplikasi three-tiered.
Dapat digunakan untuk mengembangkan client dan modul business-process. JAM / TPi
menterjemahkan dan menyebarkan modul proses pada tuxedo atau Encina transaction
processing monitor.

8.9.4.7 Open Environment Corporation (DEC)

OEC merupakan kumpulan perangkat bantu yang mempermudah pembangunan
komponen pada system three tier dengan menggunakan koneksi DCE. Sebagai contoh
akan menghasilkan “stub” RPC yang dapat dipanggil dari aplikasi client yang dibangun
dengan menggunakan PowerBuilder, VisualBasic atau produk front-end lainnya.

8.9.4.8 Greenbrier & Russel Inc

RPC Painter merupakan produk yang menjadikan OEC Entera dapat diakses secara
langsung dari PowerBuilder. RPC Painter menghasilkan PowerBuilder Data Windows
control yang menggantikan Data Windows standard untuk koneksi two-tier dengan suatu
koneksi ke suatu server non database, seperti business process server, dengan
menggunakan metoda pemanggilan DCE RPCl.

Powersoft Corporation
PowerBuilder telah menyediakan connection objek yang memudahkan koneksi dari
client PowerBuilder ke middle-tier server atau ke PowrBuilder client lainnya.

8.9.4.9 Magna Software Corporation

Magna X adalah suatu produk perangkat bantu development grafis untuk membangun
middle tier pada aplikasi three tier, dapat bekerja dengan Tuxedo, Enchina atau Entera
dan mendukung koneksi ke system mainframe IBM.

8.9.4.10 Novell’s Tuxedo dan Transarc’s Enchina

Tuxedo dari Novell, Enchina dari IBM merupakan perangkat bantu monitor proses
transaksi. Kegunaan utamanya untuk mendukung system three-tiered. Kegunaan utama
adalah untuk menyediakan suatu interface antara client dan database server pada
lingkungan transaksi yang kompleks, terutama bila berbagai database terlibat. Program
ini menyediakan satu pengukuran kendali, sebagai contoh transaksi silang antar server.
Juga mungkin untuk menggunakan produk ini sebagai middle-tier. Sebab program
aplikasi ini bersifat programmable, dan dapat deprogram untuk menerapkan aturan-aturan
bisnis sehingga menjadikan program ini menjadi business process server. Berbagai
produk misal, JYACC, JAM /TPI menggunakan pendekatan ini.

-oo0oo-