Data Flow Diagram dan Entity Relational Diagram

ANALYSIS TOOLS : DFD & ERD
putu.sundika@gmail.com
facebook.com/putu.sundika

Tools of Analysis : DFD & ERD
Konsep Physical World dan Logical Equivalent
Physical world atau dunia fisik adalah dunia yang nyata terjadi dan dapat kita lihat di
kehidupan sehari-hari. Dunia fisik ini sangat rumit dan kompleks dengan segala hal yang terjadi
di dalamnya. Faktor-faktor subyektivitas juga sangat kuat keberadaan dan pengaruhnya dalam
dunia fisik. Proses pengurusan KTP adalah contoh yang sederhana sebuah proses yang terjadi di
dalam sebuah dunia fisik. Masyarakat jika ingin mengurus sebuah KTP maka harus datang ke
kelurahan kemudian mengisi form data diri. Selanjutnya form tersebut akan dikirim ke
Kecamatan dan terus begitu sampai KTP tersebut jadi.

Surat Pengantar RT/RW

Kelurahan

KSK Formulir KTP Membayar ADM

Kecamatan

Bayar Restribusi Legalisasi Foto

Pengambilan KTP

Gambar 1 Contoh proses pembuatan KTP

Contoh proses pengurusan KTP secara manual dapat dilihat seperti gambar di atas. Setiap
tahapan harus betul-betul dilalui dengan menghadiri langsung ke tempatnya masing-masing.
Proses ini bisa memakan waktu lebih dari 1 (satu) hari. Ini adalah contoh yang terjadi di dunia
fisik.
Untuk membuat proses-proses bisnis di dunia fisik ini menjadi lebih efisien maka
dibuatlah sebuah program komputer yang akan menangani keseluruhan proses tersebut dalam
waktu yang jauh lebih singkat. E-KTP adalah contoh nyata dari implementasi sistem komputer
tersebut. Program komputer ini disebut sebagai logical world. Jadi untuk membuat physical

putu.sundika@gmail.com 2

world menjadi lebih efisien maka physical world tersebut akan diterjemahkan / dicarikan
ekivalennya ke dalam logical world, contohnya adalah dengan membuat program komputer.

Analogi Logical Equivalent
Analogi menterjemahkan physical world ke dalam logical equivalent membutuhkan
teknik khusus. Hal tersebut disebabkan karena logival equivalent tidak boleh bersifat ambiguous
atau rancu. Sifatnya harus betul-betul standard dan terlepad dari faktor-faktor seubjektifitas
sehingga setiap orang yang capable di bidangnya dapat membaca dan mengartikannya dalam
sebuah pemahaman yang sama.

Keluarga Arsitek Developer

Gambar 2 Proses membangun sebuah rumah

Gambar 2 menggambarkan proses pembangunan rumah. Proses ini dapat digunakan
untuk penggambaran sederhana tentang logical equivalent. Untuk membangun sebuah rumah
kita akan membeli tanah tempat rumah kita akan didirikan. Kemudian kita akan menghubungi
Arsitek. Pertanyaan pertama dari seorang Arsitek biasanya adalah “rumah seperti apa yang Anda
inginkan ?”. Kita akan mulai menggambarkan rumah yang kita inginkan. Misalkan kita
menginginkan halaman yang luar, pintu pagar yang tinggi, ada kolam renang dan sebagainya.
Proses yang kita lakukan ini sebenarnya adalah proses menggambarkan physical world
yang kita inginkan kepada Arsitek. Arsitek akan menterjemahkan semua penggambaran kita
tersebut ke dalam sebuah gambar (prototype). Gambaran physical world tadi akan kita lihat dan
mungkin kita revisi lagi sehingga terjadi diskusi interaktif antara kita dan Arsitek. Sampai suatu
saat tercapai kata sepakat maka Arsitek dengan tool yang dimilikinya akan membuat sebuah
gambar teknis atau blueprint. Gambar teknis ini lah yang disebut sebagai logical ekuivalent dari
physical world. Blueprint ini tidak dapat dibaca oleh kita sebagai customer, tetapi sangat jelas
dapat dibaca oleh kontraktor pemangun rumah. Blueprint tersebut berisikan seluruh spesifikasi


teknis dari rumah yang harus dibangun. Blueprint tidak mengandung informasi yang ambiguous /
rancu. Hal ini menyebabkan seorang kontraktor tidak perlu berdiskusi dengan customer / pemilik
rumah. Kontraktor cukup berdiskusi dengan Arsitek. Dan itupun dilakukan dengan frekuensi
yang minimal. Hal ini dikarenakan semua informasi yang diperlukan sudah ada di dalam
blueprint. Setelah rumah selesai dibangun, blueprint ini sebagai dokumentasi teknis dari rumah
akan diberikan kepada customer.
Penggambaran proses di atas dapat kita samakan dengan dunia komputer. Dimana
seorang customer yang memesan program dapat dipandang sebagai keluarga pemesan rumah
tadi. Arsitek dapat dipandang sebagai System Analyst. Kontraktor pembangun rumah dapat
dipandang sebagai seorang software developer.

Customer System Analyst Software Developer

Gambar 3 Proses membangun sebuah program

System analyst akan menanyakan sedetil-detilnya tentang kebutuhan dan keinginan dari
customer. Setelah diskusi interaktif dan menemukan kesepatan, System Analyst akan membuat
sebuah bisnis flow serta dokumen teknis lainnya. Data Flow Diagram (DFD) dan Entity Relation
Diagran (ERD) adalah salah satu tool yang dapat digunakan untuk membuat logical ekuivalent
ini. Seorang programmer komputer atau software developer tidak akan merasa perlu lagi
bertanya dan berdiskusi kepada customer. Hal ini dikarenakan semua hal teknis yang terkait
dengan keperluan pembuatan software sudah ada dan diberikan oleh Analyst. Walaupun physical
world penuh dengan subyektivitas, dokumen teknis tetap dibuat dengan pendekatan matematika.

Dokumentasi Teknis
Data Flow Diagram selain merupakan diagram yang menterjemahkan physical world ke
logical equivalent, DFD juga adalah dokumentasi dari software. Dokumentasi teknis ini sangat
sangat penting dikarenakan sifat standard dan non ambiguous nya. Contoh pentingnya


dokumentasi ini dapat kita lihat pada contoh kasus pembuatan rumah di atas. Blueprint rumah
yang sudah dibuatkan oleh Arsitek adalah dokumentasi teknis dari rumah. Jika setelah beberapa
waktu, rumah yang sudah berdiri dan ditempati ingin diubah / renovasi maka tentunya kita akan
menghubungi Arsitek yang sama saat pertama kita bangun rumah. Semisal Arsitek tersebut
sudah tidak ada, misalkan pensiun atau sejenisnya, maka dengan memanfaatkan dokumentasi
(blueprint) yang sudah ada, kita cukup menghubungi Arsitek yang lain dengan membawa
dokumen tadi. Arsitek yang baru tidak perlu lagi menghubungi Arsitek sebelumnya karena
dokumentasi teknisnya sudah jelas.
Demikian juga halnya dengan Data Flow Diagram yang sudah dimiliki, cukup diberikan
kepada System Analyst yang baru untuk revisi atau mungkin langsung ke software developer
untuk dibuatkan perubahannya.

Simbol Data Flow Diagram
Untuk membuat sebuah Data Flow Diagram, dibutuhkan setidaknya 4 simbol logical
equivalent yaitu symbol yang menggambarkan proses, entitas luar, data flow dan data store.

Entitas luar Proses Data Flow Data Store

Gambar 4 Simbol DFD

Entitas luar / external adalah entitas yang tidak dapat dikontrol. Data Flow dan Data Store
adalah 2 hal yang berlawanan. Data Flow adalah data yang bergerak atau aliran data dari dan ke.
Sedangkan Data Store tidak bergerak alias menetap, biasanya Data Store adalah representative
dari database. Contoh yang sederhana yang dapat dibuatkan logical equivalentnya adalah proses
pembayaran dari pembelian barang. Proses yang terjadi di physical world adalah sebagai berikut.
Vendor atau supplier akan mengirimkan invoice kepada customer. Customer setelah menerima
invoice tersebut akan menyimpannya di buku kas. Setelah 30 hari kerja invoice tersebut akan
diterbitkan.



1.0
Mencatat
invoice cek
Supplier dan Supplier
Membayar

mencatat dan melihat
Buku Kas

Gambar 5 Data Flow Diagram pembayaran invoice

Gambar 5 adalah logical equivalent dari physical world invoice di atas tadi. Data Flow
Diagram pada gambar 5 terbentuk dari 2 eksternal, 1 proses, 2 data flow dan 1 data store. Jika
dilihat lagi maka proses 1.0 terdiri dari 2 proses yaitu proses mencatat dan proses membayar.
Artinya proses 1.0 ini masih bisa kita breakdown lagi menjadi proses kecil. Peristiwa memecah
ke proses yang lebih detil lagi disebut sebagai decomposisi atau lebih dikenal dengan leveling.

1.1 1.2
invoice cek
Supplier mencatat membayar Supplier

menyimpan membaca
Buku Kas

Gambar 6 Data Flow Diagram yang lebih detil

Hasil leveling dari gambar 5 menjadi gambar 6. Terlihat jelas bahwa pada physical world
tentang invoice tadi setelah di logival equivalent mendapatkan 2 proses dengan 2 eksternal yang
terkait.
Perbedaan pasti dari physical dan logical adalah bahwa logical merupakan hal yang tidak
mengandung kerancuan lagi, sehingga DFD sebagai logical quivalent merupakan sebuah
informasi standard yang dapat dimengerti oleh seluruh system analyst, programmer atau software
developer sebagai sebuah gambaran proses physical world.


LOGIC MODELLING
Setelah membuat logical equivalent yaitu Data Flow Diagram, maka selanjutnya adalah
melakukan pemodelan dari logic tadi. Hal ini sangat erat berhubungan dengan desain dari sebuah
database yang akan digunakan. Logic modeling mempunyai tujuan akhir yaitu menentukan
hubungan terbaik / relasi yang paling tepat untuk diterapkan di database.

Order No : _________________________________ ORDER FORM
Order Date : _________________________________
Customer No : _________________________________
Customer Name : _________________________________
Customer Addres : _________________________________
Item No Item Qty Item Price Item Name Item Amount

TOTAL

Gambar 7 Contoh sebuah order form

Gambar 7 adalah sebuah contoh dari order form yang sering digunakan di restoran atau di
tempat perbelanjaan umum. Ketika customer membeli beberapa barang dari sebuah toko maka
form order ini akan diisi. Jika diperhatikan lagi makan order form di atas terdiri dari 2 bagian
besar yaitu bagian header dan bagian detil. Bagian header adalah bagian yang berisikan
informasi Order No, Order Date sampai Customer Address. Sedangkan bagian detil berisikan
barang-barang yang dibeli. Order form pada gambar 7 ini akan digunakan sebagai contoh desain
database yang baik.

Logic Data Model
Setidaknya ada 3 (tiga) hal pokok yang harus dilakukan dalam membuat sebuah model
data logic. Inilah nanti yang akan membentuk Entity Relation Diagram (ERD).
1. Mengindentifikasi Candidate Key
2. Memilih Primary Key
3. Melakukan normalisasi


Candidate Key dan Primary Key
Key seperti jika ditermahkan ke dalam Bahasa Indonesia berarti kunci. Key adalah
sesuatu yang unik yang bisa digunakan untuk mewakili sesuatu. Contoh seorang mahasiswa.
Yang dapat mewakili seorang mahasiswa tertentu adalah bukan namanya sebab nama mungkin
saja sama antara mahasiswa satu dengan lainnya. Yang dapat digunakan sebagai key adalah
Nomor Induk Mahasiswanya (NIM). NIM tidak mungkin sama untuk lebih dari seorang
mahasiswa. Jika key adalah NIM maka artinya cukup dengan memanggil NIM saja maka kita
bisa mengetahui data dari mahasiswa tersebut, misalkan nama, umur, kelas, alamat dan yang
lainnya. Key juga berhubungan dengan pencarian. Jadi jika ingin mencari data mahasiswa, cukup
digunakan NIM nya untuk key pencarian.
Ternyata NIM bukanlah satu-satunya key yang mungkin digunakan pada data mahasiswa.
Ada No KTP yang juga bisa digunakan sebagai key. Sehingga sekarang kita punya 2 (dua) key.
Inilah yang disebut sebagai candidate key. Salah satu dari candidate key ini harus dipilih sebagai
pemenang. Pemenang akan disebut sebagai Primary Key. Sisanya disebut secondary key. Cara
memilihnya adalah dengan mempertimbangkan yang mana yang akan paling sering digunakan.
Jika data mahasiswa, maka tentunya yang akan paling sering digunakan adalah NIM nya.
Sehingga Primary Key yang digunakan adalah NIM.

Normalisasi
Konsep normalisasi adalah konsep yang harus dipatuhi dalam membuat desain relasi dari
sebuah database. Dengan memenuhi semua konsep normalisasi ini maka desain relasi database
akan membuat sebuah hubungan terbaik sehingga integritas dari database dapat terjaga dalam
kondisi yang sempurna. Konsep dasar dari normalisasi adalah menghilangkan redundansi atau
perulangan pada desain database. Contoh yang paling sederhana adalah ketika kita mempunyai 3
(tiga) field yaitu quantity, price dan amount. Amount dalam hal ini isinya adalah hasil perkalian
dari quantiy dan price. Hal ini adalah contoh sederhana bahwa telah terjadi redundansi yang
tidak perlu. Dengan konsep normalisasi maka seharusnya kita cukup mempunyai 2 (dua) field
saja yaitu quantity dan price.


Normal Form (NF)
Sebelum lebih jauh masuk ke dalam normalisasi, maka istilah di bawah ini adalah konsesi
yang digunakan dalam desain database.
Entity adalah logic equivalent dari sebuah file / table / database. Dalam contoh di atas, entitas
yang dimaksud adalah entitas order.
Atribut adalah elemen dari sebuah entitas. Dalam contoh di atas, atribut dari entitas order adalah
order no, order date dan seterusnya.

Aturan Dasar dari NF
 1st NF : tidak ada pengulangan atribut
 2nd NF : tidak ada ketergantungan secara partial pada Primary Key
 3th NF : tidak ada non key atribut yang tergantung terhadap non key atribut lainnya

Menggunakan contoh kasus form order di atas maka dapat kita buatkan entitas dan atribut seperti
di bawah ini :

Item No Order Date

Item Qty Customer No
Entitas : Order
Item Price Order No (PK) Customer Name

Item Total Customer Address

Item Name

Gambar 8 Entitas, Primary Key dan non key attribute

Gambar 8 menunjukkan bahwa entitas order memiliki 9 non key attribute (field) dengan
sebuah field sebagai Primary Key yaitu Order No. Gambar awal ini harus dianalisa
menggunakan konsep normalisasi untuk mendapatkan hubungan terbaik dalam databasenya.


1st NF
Normalisasi pertama menyatakan bahwa tidak boleh ada perulangan atribut. Jika kita
lihat kembali gambar 7 maka ternyata ada perulangan di sana. Satu form order bisa menangani
banyak item yang dibeli oleh customer. Sehingga jika desain seperti gambar 8 digunakan data
order hanya bisa menangani 1 item yang terbeli. Jika membeli banyak item maka akan jelas
terlihat terjadi perulangan yaitu dengan order no yang sama berulang untuk item yang berbeda.
Efek dari perulangan ini adalah kita harus mendefinisikan item maksimal yang harus dibeli
dalam sebuah order no. Hal ini tentunya sangat tidak masuk akal. Dalam dunia nyata hal ini
seperti membuatkan nota baru untuk setiap kali berbelanja lebih dari sekian item. Untuk itu
perlu dinormalisasi.

Entitas : Order Items Entitas : Order

Order No Item No (PK) Order No (PK)

Item Qty Order Date

Item Price Customer No

Item Total Customer Name

Item Name Customer Address

Gambar 9 Hasil setelah 1st NF

Aturan yang dapat digunakan dalam membuat 1st NF adalah setiap kali terjadi kegagalan
di 1st NF maka harus dibuat sebuah entitas baru dengan menggunakan key bersambung atau
concatenated key seperti terlihat pada entitas baru Order Items yang menggunakan concatenated
key dari Item No dan Order No.

2nd NF
Setelah 1st NF tercapai maka perlu dianalisa menggunakan aturan 2nd NF bahwa non key
attribute yang ada pada concatenated key, tidak boleh ada ketergantungan secara partial. Jika kita
lihat kembali gambar 9 pada entitas Order Items, non key attribute Item Name hanya bergantung


pada concatenated Item No. Item Name tidak bergantung pada Order No. Hal ini dikatakan
bahwa ada non key attribute yang tergantung secara partial terhadap concatenated key.

Entitas : Order Items Entitas : Items Entitas : Order
Order No Item No (PK) Item No (PK) Order No (PK)

Item Qty Item Price Order Date

Item Total Item Name Customer No

Customer Name

Customer Address

Gambar 10 Hasil setelah 2nd NF

3rd NF
Terakhir adalah melakukan analisa terhadap kepatuhan aturan normalisasi 3rd NF yaitu
tidak boleh ada non key attribute yang saling tergantung. Jika dilihat pada gmabar 10 di atas
maka dapat dilihat bahwa Customer No, Customer Name dan Customer Address semuanya
saling tergantung. Untuk itu perlu dibuatkan sebuah entitas baru.

Entitas : Order Items Entitas : Items

Order No Item No (PK) Item No (PK)

Item Qty Item Price

Item Total Item Name

Entitas : Customer Entitas : Order

Customer No (PK) Order No (PK)

Customer Name Order Date

Customer Address
Gambar 12 Hasil setelah 3th NF


Gambar 12 menunjukkan bahwa seluruh proses sudah di normalisasi. Item Total pada
entitas Order Item bisa dihilangkan karena total merupakan hasil perkalian dari Item Quantity
dan Item Price.

Entity Relation Diagram (ERD)
Setelah memastikan desain database sudah normal maka hubungannya antar entitas akan
dibuatkan sebuah diagram hubungan yang disebut sebagai Entity Relational Diagram (ERD).
Jenis hubungan yang dimungkinakan terjadi dalam ERD adalah one to many, one to one dan zero
to many. Hubungan ini sering juga disebut sebagai cardinality. Simbolnya dapat dilihat pada
gambar ERD dibawah ini.

Order Item
Order No Item No

Order Date Item Price
Customer No (FK) Item Order Item Name
Order No Item No
Cust Item Qty
Customer No

Customer Name
Customer Address

Gambar 13 Entity Relational Diagram

Gambar 13 merupakan hasil akhir dari penggambaran ERD. Cara mendapatkan gambaran
seperti itu adalah dengan cara memulai melihat hubungan per entitas. Misalkan dimulai dari
entitas Order terhadap entitas Item Order. Digambarkan sebagai one to many. Dikarenakan
sebuah order no memiliki minimal sebuah item yang di order atau banyak.Sedangkan sebaliknya
entitas Item Order ke Order hubungannya adalah one to one. Untuk entitas Item terhadap Item
Order hubungannya adalah zero to many. Hal ini dikarenakan bahwa sebuah item yang ada tidak
pernah diorder atau sebuah item justru bisa banyak diorder. Sebaliknya, hubunga antara entitas
Item Order terhadap Items adalah one to one. Hubungan entitas Order terhadap Customer adalah


one to one mengingat sebuah no order pastilah kepunyaan seorang customer saja. Sebaliknya
adalah hubungan one to many karena seorang customer bisa memiliki banyak order.

Penutup
Data Flow Diagram (DFD) dan Entity Relational Diagram (ERD) adalah tools yang bisa
digunakan untuk melakukan dokumentasi teknis dari physical world ke logic equivalent.
Hasilnya adalah sebuah dokumentasi teknis yang standard yang dapat dimengerti oleh orang-
orang yang terkait dalah sofwater life cyle seperti system anlyst dan software developer.


Data Flow Diagram dan Entity Relational Diagram

More Related Content

Viewers also liked (18)

Recently uploaded (20)

Data Flow Diagram dan Entity Relational Diagram