13
ANALYSIS TOOLS : DFD & ERD [email protected] facebook.com/putu.sundika

Data Flow Diagram dan Entity Relational Diagram

Embed Size (px)

DESCRIPTION

tutorial singkat dalam bahasa Indonesia tentang konsep dari DFD (Data Flow Diagram) dan ERD (Entity Relational Diagram). tutorial ini dilengkapi dengan contoh detil tentang cara membangun kedua diagram ini. [email protected]

Citation preview

Page 1: Data Flow Diagram dan Entity Relational Diagram

ANALYSIS TOOLS : DFD & ERD [email protected]

facebook.com/putu.sundika

Page 2: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

2

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.

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

Surat Pengantar RT/RW

Kelurahan

Formulir KTP KSK Membayar ADM

Kecamatan

Legalisasi Bayar Restribusi Foto

Pengambilan KTP

Page 3: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

3

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.

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

Keluarga Arsitek Developer

Page 4: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

4

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.

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

Customer System Analyst Software Developer

Page 5: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

5

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.

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.

Entitas luar Proses Data Store Data Flow

Page 6: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

6

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.

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.

Supplier Supplier

1.0

Mencatat

dan

Membayar

Buku Kas

invoice cek

mencatat dan melihat

Supplier Supplier

Buku Kas

invoice cek

menyimpan

1.1

mencatat

1.2

membayar

membaca

Page 7: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

7

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.

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

Order No

Order Date

Customer No

Customer Name

Customer Addres

: _________________________________

: _________________________________

: _________________________________

: _________________________________

: _________________________________

ORDER FORM

Page 8: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

8

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.

Page 9: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

9

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 :

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.

Item No

Item Qty

Item Price

Item Total

Item Name

Order Date

Customer No

Customer Name

Customer Address

Order No (PK)

Entitas : Order

Page 10: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

10

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.

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 2

nd 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

Item Qty

Item Price

Item Total

Item Name

Order Date

Customer No

Customer Name

Customer Address

Order No (PK)

Entitas : Order

Order No Item No (PK)

Entitas : Order Items

Page 11: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

11

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.

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.

Gambar 12 Hasil setelah 3th

NF

Item Qty Item Price

Item Total Item Name

Order Date

Customer No

Customer Name

Customer Address

Order No (PK)

Entitas : Order

Order No Item No (PK)

Entitas : Order Items

Item No (PK)

Entitas : Items

Item Qty Item Price

Item Total Item Name

Order Date

Customer No (PK)

Customer Name

Customer Address

Order No (PK)

Entitas : Order

Order No Item No (PK)

Entitas : Order Items

Item No (PK)

Entitas : Items

Entitas : Customer

Page 12: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

12

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.

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

Order No

Order Date

Customer No (FK)

Item No

Item Price

Item Name

Customer No

Customer Name

Customer Address

Order No Item No

Item Qty

Item Order

Item Order

Cust

Page 13: Data Flow Diagram dan Entity Relational Diagram

Tools of Analysis : DFD & ERD

[email protected]

13

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.