Cara Praktis Merancang Database

Kuliah Umum 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.
Latar Belakang
Ide tulisan ini berasal dari milis Ilmukomputer.com yang mendiskusikan bagaimana
merancang database. Cara praktis dalam tulisan ini tidak menggunakan teknik
normalisasi secara eksplisit atau formal, melainkan berdasar pengalaman penulis
merancang berpuluh database berbagai ukuran dan kompleksitas, mulai dari yang
modelnya memiliki kurang dari 25 tabel sampai dengan yang memiliki lebih dari 250
tabel. Database tersebut untuk berbagai macam sistem dan aplikasi, baik batch di
mainframe, client/server, web-based, business oriented maupun real-time control
system.
One Step at A Time
Kasus dalam tulisan ini adalah: Merancang database relasional untuk menyimpan data
“stok barang” - ini adalah ruang-lingkupnya (scope)
Dari spesifikasi yang sudah diperoleh dari pemakai (business user), kita ketahui bahwa
yang dimaksud dengan stok barang adalah jumlah tersedia (quantity on hand) untuk
setiap barang. Maka kita membutuhkan tabel stok_barang terdiri dari 2 kolom.
Beberapa baris datanya sebagai berikut.
nama_barang
…
Barang A
Barang B
Barang C
Barang D
…
jumlah_tersedia
…
100
150
175
250
…
1

Kuliah Umum IlmuKomputer.Com
Copyright © 2003 IlmuKomputer.Com
Perhatikan bahwa setiap barang hanya memiliki satu jumlah_tesedia. Dengan kata
lain, nama barang unik didalam tabel stok_barang.
Spesifikasi juga meminta rancangan database kita untuk menangani transaksi
pembelian dan penjualan barang, dan dampaknya pada stok barang. Tepatnya, bila ada
barang masuk (pembelian) dan/atau keluar (penjualan), jumlah_tersedia perlu
dimutakhirkan (update).
Ada dua pilihan cara melaksanakannya:
1. Jumlah barang masuk/keluar langsung ditambah/kurang-kan pada kolom
jumlah_tersedia (update in place). Cara ini umumnya disebut sistem online. Data
transaksi keluar/masuk barang disimpan, misalnya untuk keperluan audit atau
rekonstruksi tabel stok_barang.
2. Data transaksi barang masuk dikumpulkan, setelah waktu tertentu, misalnya
akhir hari, barulah diperhitungkan ke jumlah_tersedia. Cara ini disebut sistem
batch.
Maka, untuk cara yang manapun dari kedua diatas, dibutuhkan satu tabel lagi untuk
menyimpan data transaksi, misalnya sebagai berikut.
nama_barang
…
Barang A
Barang A
Barang B
…
jumlah
…
1
10
5
…
masuk/keluar
…
m
k
k
…
tanggal
…
2-Jan-04
5-Jan-04
10-Jan-04
…
Agar nama barang dikedua tabel sinkron, maksudnya semua nama barang ditabel
transaksi_stok harus ada ditabel stok_barang, maka kedua tabel kita hubungkan:
nama_barang ditabel stok_barang kita migrasikan ketabel transaksi_stok. Dengan
kata lain, nama_barang ditabel transaksi_stok adalah foreign key dengan referensi
nama_barang ditabel stok_barang. Diagram ER (Entity Relationship) model data
sebagai berikut.
2

Kuliah Umum IlmuKomputer.Com
Copyright © 2003 IlmuKomputer.Com
Perhatikan bahwa pada transaksi_stok, nama_barang dan tanggal adalah (composite)
primary key. Ini berarti dalam satu hari (tanggal) untuk suatu barang hanya boleh ada
satu transaksi.
Lebih lanjut, spesifikasi menyatakan bahwa, ada beberapa gudang, dan suatu barang
mungkin stoknya disimpan dibeberapa gudang (dan suatu gudang bisa menyimpan
lebih dari satu barang) Maka perlu ditambahkan data gudang. Struktur tabel kita
menjadi sebagai berikut.
nama_barang
…
Barang A
Barang A
Barang B
Barang C
Barang C
Barang D
…
gudang
…
Gudang 1
Gudang 2
Gudang 1
Gudang 2
Gudang 3
Gudang 3
jumlah_tersedia
…
100
10
150
175
20
250
…
Perhatikan bahwa setiap barang disuatu gudang hanya memiliki satu jumlah_tesedia.
Dengan kata lain, nama_barang bersama gudang-nya unik didalam tabel stok_barang.
Kini primary key tabel ini adalah nama_barang dan gudang. Dan, model data menjadi:
Karena oleh pemakai setiap barang sudah terbiasa diberi kode, maka dalam database
kode barang juga diinginkan, selain namanya. Pemakai juga memastikan didalam
spesifikasi, bahwa kode barang tidak pernah berubah, sedang nama barang kadang
perlu diubah, maka kita gunakan kode_barang sebagai primary key. Berkembanglah
model data kita menjadi:
3

Kuliah Umum IlmuKomputer.Com
Copyright © 2003 IlmuKomputer.Com
Contoh isi tabel stok_barang sekarang adalah:
kode_barang
…
A01
A01
B01
C01
C01
D01
nama_barang
…
Barang A
Barang A
Barang B
Barang C
Barang C
Barang D
…
gudang
…
Gudang 1
Gudang 2
Gudang 1
Gudang 2
Gudang 3
Gudang 3
jumlah_tersedia
…
100
10
150
175
20
250
…
Dapat dilihat, nama barang ikut diulang bersama kode barangnya. Akibatnya, bila ada
perubahan nama, semua baris data barang bersangkutan harus seragam ikut dirubah
dan barang ditabel ini sudah diwakili oleh kode_barang. Ini berbahayakan integritas
data; maka sebaiknya dipisahkan, sebagai berikut.
4

Kuliah Umum IlmuKomputer.Com
Copyright © 2003 IlmuKomputer.Com
Ringkasan
Laksanakan langkah-langkah demi langkah, jangan sekaligus menganalisa dan
merancang semua data dalam spesifikasi.
1. Mulai dengan minimal, satu tabel, berdasar makna fungsi yang dibutuhkan. Dalam
contoh kita, makna stok barang adalah quantity on hand untuk setiap barang.
2. Kembangkan struktur dari tabel ini, dengan makin menyertakan detil spesifikasi.
Dalam contoh kita, quantity on hand disetiap gudang – maka perlu ditambahkan
field “gudang”. Demikian juga dengan penambahan kode_barang.
3. Bila ada duplikat data (data sama di lebih dari satu baris) dan sudah ada wakilnya
pisahkanlah ditabel lain yang dihubungkan dengan tabel asalnya.
4. Fungsi berbeda biasanya memerlukan tabel terpisah; dalam contoh kita, fungsi
“transaksi stok”. Kita perlu tabel untuk menyimpan transaksi. Hubungkan dengan
tabel utama (umumnya disebut master dalam system batch) agar data terkait
dikedua tabel sinkron (integritas terjaga)
Makin besar dan rumit database yang harus kita rancang, teknik praktis ini makin
lebih terbukti efektivitasnya, dibandingkan dengan menggunakan teknik normalisasi
secara formal.