Fan Traps

Tips dan Trik IlmuKomputer.Com
Copyright © 2003 IlmuKomputer.Com

Djoni Darmawikarta
djoni_darmawikarta@yahoo.ca
Lisensi Dokumen:
Copyright © 2003 IlmuKomputer.Com
Seluruh dokumen di IlmuKomputer.Com dapat digunakan, dimodifikasi dan disebarkan
secara bebas untuk tujuan bukan komersial (nonprofit), dengan syarat tidak menghapus
atau merubah atribut penulis dan pernyataan copyright yang disertakan dalam setiap
dokumen. Tidak diperbolehkan melakukan penulisan ulang, kecuali mendapatkan ijin
terlebih dahulu dari IlmuKomputer.Com.
Sebuah departemen pemerintah memiliki banyak gedung kantor diseluruh penjuru
tanah air. Divisi Pengelola Fasilitas Kantor ingin membangun sistem informasi yang
salah satu fungsinya adalah pemberdayaan tempat kerja (space efficiency). Untuk itu
perlu inventaris unit kerja dan staf digedung-gedung kantornya.
Sewaktu pengumpulan kebutuhan berlangsung, spesifiknya yang berkenaan dengan
data yang akan disimpan didalam database, pimpinan pengelola fasilitas kantor
menginginkan sistem untuk mampu menjawab pertanyaan: Unit-kerja apa dan staf
siapa saja yang ada disetiap gedung?
Maka diagram data model yang dibuat berbentuk sebagai:
GEDUNG
UNIT_KERJA
# UNITKERJA_KEY
* NAMA_UNITKERJA
ada di
ditempati oleh
# GEDUNG_KEY
* NAMA_GEDUNG
ditempati oleh
ada di
STAF
# STAF_KEY
* NAMA_STAF
Catatan: Atribut dengan akhiran _KEY adalah surrogate key (lihat tulisan saya nomor 4: SURROGATE KEY,
di IKC).
Contoh data ketiga tabel ini adalah:
Gedung_KEY
1
2
Gedung_KEY
1
2
2
2
Nama_gedung
Gedung I
Gedung II
Unitkerja_KEY
1
1
2
3
Nama_unitkerja
UK a
UK a
UK b
UK c
Gedung_KEY
1
2
2
2
1
1
1
2
Staf_KEY
1
2
3
4
5
6
7
8
Nama_staf
Staf A
Staf B
Staf C
Staf D
Staf E
Staf F
Staf G
Staf I
1

Tips dan Trik IlmuKomputer.Com
Copyright © 2003 IlmuKomputer.Com
Sewaktu menemui pimpinan SDM dan Organisasi 1 terungkap kebutuhan untuk
menjawab pertanyaan: Digedung mana saja unit-kerja menempatkan staf-nya?
Dengan kata lain, harus diketahui unit-kerja dari staf yang ada disetiap gedung; tidak
cukup hanya mengetahui ‘apa’ saja (unit-kerja dan staf) yang ada disetiap gedung. Data
model diatas tidak bisa menjawab kebutuhan ini, karena hubungan Unit-kerja dan Staf,
melalui Gedung, tidak pasti (ambiguous relationship)
Karena bentuknya seperti kipas (dari satu entity keluar kebanyak entity-entity lain),
dan kekurangannya (hubungan yang tidak pasti antara entity disekelilingnya), pola
data model (pattern) seperti ini diistilahkan fan trap (jebakan kipas).
Untuk menjawab sekaligus kedua kebutuhan diatas, data modelnya haruslah sebagai
berikut:
GEDUNG
# GEDUNG_KEY
* NAMA_GEDUNG
ditempati oleh
ada di
UNIT_KERJA
# UNITKERJA_KEY
* NAMA_UNITKERJA
penempatan
ada di
STAF
# STAF_KEY
* NAMA_STAF
Catatan: Garis vertikal diujung entity UNIT_KERJA pada hubungan entity GEDUNG dengannya
menandakan bahwa primary key dari GEDUNG (GEDUNG_KEY) di-migrate ke UNIT_KERJA sebagai
primary key (hubungan semacam ini disebut identifying relationship, lihat tulisan saya nomor 20: WEAK
ENTITY dan IDENTIFYING RELATIONSHIP, di IKC), karena kita membutuhkan GEDUNG_KEY sebagai
atribut di entity STAF.
Contoh data ketiga tabel ini adalah:
Gedung_KEY
1
2
Nama_gedung
Gedung I
Gedung II
Gedung_KEY
1
2
2
2
Staf_KEY
1
2
3
4
5
6
7
8
Nama_staf
Staf A
Staf B
Staf C
Staf D
Staf E
Staf F
Staf G
Staf I
Unitkerja_KEY
1
1
2
3
Nama_unitkerja
UK a
UK a
UK b
UK c
Gedung_KEY
1
2
2
2
1
1
1
2
Unitkerja_KEY
1
1
3
2
1
1
1
3
TIPS
Bila sewaktu merancang database data modelnya memiliki suatu entity yang keluar
menghubungi sejumlah entity, selidikilah lebih teliti untuk menghindari fan trap.
1
Pengumpulan kebutuhan dari unit terkait ini diperlukan karena keterpaduan melalui database merupakan
strategi utama pembangunan sistem informasi di departemen pemerintah ini.