Perbedaan Client-Server dan Web Based

Client-Server adalah arsitektur jaringan yang memisahkan client(biasanya aplikasi yang menggunakan GUI ) dengan server. Masing-masing client dapat meminta data atau informasi dari server. Sedangkan Web Based Web based jika diartikan ke bahasa Indonesia, "berbasis-web", atau "berbasis internet". Dapat diartikan sebagai segala sesuatu yang dapat diakses lewat web. Seperti layanan mail yahoo, wikimu juga dikatakan sebagai "sesuatu" (read:forum) yang berbasis web, yang dapat diakses lewat internet.

Kelebihan & Kekurangan Client-server - Web Based

Client-server

•Kelebihan

–Beban komputasi disebar di beberapa mesin

–Client mengakses fungsionalitas server dari jarak jauh

–Client dan server didesain terpisah (dan mungkin berbeda), lebihsederhana dibanding mendesain satu program yang dapat melakukan segalanya

–Data dapat disimpan secara terpusat di server, usaha menjaga reliabilitas sistem cukup dilakukan di server (UPS, redundant disk array, high speed processors, dll)

–Data dapat disimpan secara terdistribusi di banyak client atau server, sehingga jika satu komponen rusak (misalnya harddisk crash atau bencana alam), maka data yang hilang menjadi minimal, atau mungkin dapat digantikan oleh data dari komponen lain

–Server dapat diakses secara simultan oleh banyak client

•Kekurangan

–Adanya delay komunikasi client-server

–Harus mempertimbangkan sinkronisasi dan paralelisme proses dalammendesain server

Web Based

Kelebihan:

• Dapat diakses kapan pun dan dari mana pun selama ada internet
• Dapat diakses hanya dengan menggunakan web browser (umumnya sudah tersedia di PC, PDA, danhandphone terbaru), tidak perlu menginstall aplikasi client khusus

Kekurangan:

• Antarmuka yang dapat dibuat terbatas sesuai spesifikasi standar untuk membuat dokumen web dan keterbatasan kemampuan web browser untuk menampilkannya
• Terbatasnya kecepatan internet mungkin membuat respon aplikasi menjadi lambat

Sumber:

www.wimpermana.web.ugm.ac.id/budi_s/wp.../client_server.pdf 

imam.staff.gunadarma.ac.id/Downloads/files/.../01-Pemrograman+Internet.pdf

http://purnamayasa.wordpress.com/2010/03/05/kelebihan-kekurangan-aplikasi-berbasis-web/

http://www.wikimu.com/News/DisplayNews.aspx?id=5572

Teknik Pengukuran Performance Basisdata

Optimasi SQL

Source : http://www.pcmedia.co.id


Database bagaikan seorang sahabat yang patuh dan mengerti pada setiap perintah yang diberikan, sayangnya terkadang tidak berlaku sebaliknya, kita tidak patuh dan tidak mengerti pada “perintah” yang diberikan database.
Database kadang dapat “mengomel” dengan berbagai cara, bisa jadi dalam bentuk performance yang menurun, pesan kesala  han, atau bahkan hasil laporan yang tidak sesuai. Semua-nya dapat kita minimalisasi, bahkan sebelum hal itu terjadi. Dengan cara  melakukan Otimasi.
Optimasi dapat dilakukan dengan berbagai cara, dengan memahami tuning performance pada database dan best practice dari berbagai sumber..
Beberapa teknik dan metoda mungkin memerlukan perlakuan khusus yang berbeda, tergantung pada database yang Kita  gunakan.
Optimasi melalui perintah SQL juga memegang peranan   yang tidak kalah penting. Inti dari SQL itu sendiri adalah perintah untuk melakukan pengambilan (retrieval), penambahan (insertion), modifikasi (updating), dan penghapusan (deletion) data, disertai dengan fungsi-fungsi pendukung administrasi dan managemen database. Beberapa hal yang harus kita optimasi, diantaranya :


Index
Index dapat meningkatkan kecepatan pencarian pada record yang diinginkan. Tetapi, harus cukup selektif dalam memilih field yang perlu di-index, karena tidak semua field memerlukannya.
Ibaratnya membaca buku, proses pencarian atau scan akan membaca dari awal hingga akhir halaman. Pada field yang di-index, pencarian dilakukan secara index scan, atau membaca pada index, tidak langsung pada table yang bersangkutan.
Sementara pencarian yang dilakukan langsung dengan membaca record demi record pada table disebut dengan table scan.
Apakah index scan selalu lebih cepat dibandingkan dengan table scan? Ternyata tidak juga, table scan bisa jadi bekerja lebih cepat saat mengakses record dalam jumlah relatif kecil, ataupun pada saat aplikasi memang memerlukan pembacaan table secara keseluruhan.
Sebaliknya dalam mengakses record yang besar pada field tertentu, index scan dapat mengurangi operasi pembacaan I/O sehingga tidak jarang menghasilkan kinerja yang lebih cepat.
Sebagai patokan, Kita dapat menentukan index pada field yang sering digunakan, misalnya field yang sering diakses oleh klausa WHERE, JOIN, ORDER BY, GROUP BY.


Menentukan Tipe Data
Tipe data merupakan permasalahan yang gampang-gampang susah. Dari sisi daya tampung, tipe data yang terlalu kecil atau sebaliknya terlalu besar bagi suatu field, dapat menimbulkan bom waktu yang menimbulkan masalah seiring dengan pertambahan data yang pesat setiap harinya.
Menentukan tipe data yang tepat memerlukan ketelitian dan analisa yang baik. Sebagai contoh, kita perlu mengetahui kapan kita menggunakan tipe data char atau varchar.
Keduanya menampung karakter, bedanya char menyediakan ukuran penyimpanan yang tetap (fi  xed-length), sedangkan varchar menyediakan ukuran penyimpanan sesuai dengan isi data (variable-length).
Patokan umum adalah menggunakan tipe data char jika field tersebut diperuntukkan untuk data dengan panjang yang konsisten. Misalnya kode pos, bulan yang terdiri dari dua digit (01 sampai 12), dan seterusnya. Varchar digunakan jika data yang ingin disimpan memiliki panjang yang bervariasi, atau gunakan varchar(max) jika ukurannya melebihi 8000 byte.


Jangan Izinkan Allow Null
Jika memungkinkan, kurangi penggunaan field yang memperbolehkan nilai null. Sebagai gantinya, Kita  dapat memberikan nilai default pada field tersebut.
Nilai null kadang rancu dalam intepretasi programer dan dapat mengakibatkan kesalahan logika pemrograman. Selain itu, field null mengonsumsi byte tambahan sehingga menambah beban pada query yang mengaksesnya.


Query yang Mudah Terbaca
Karena SQL merupakan bahasa declarative, maka tidak mengherankan jika Kita  membuat query berbentuk kalimat nan panjang walaupun mungkin hanya untuk keperluan menampilkan satu field!
Jangan biarkan query Kita  susah dibaca dan dipahami, kecuali Kita  memang berniat membuat pusing siapapun yang melihat query Kita . Query panjang yang ditulis dalam 1baris jelas akan menyulitkan modifi  kasi dan pemahaman, akan jauh lebih baik jika Kita  menuliskan query dalam format yang mudah dicerna.
Pemilihan huruf besar dan kecil juga dapat mempermudah pembacaan, misalnya dengan konsisten menuliskan keyword SQL dalam huruf kapital, dan tambahkan komentar bilamana diperlukan.


Hindari SELECT *
Select mungkin merupakan keyword yang paling sering digunakan, karena itu optimasi pada perintah  SELECT sangat mungkin dapat memperbaiki kinerja aplikasi secara keseluruhan. \
SELECT * digunakan untuk melakukan query semua field yang terdapat pada sebuah table, tetapi jika Kita  hanya ingin memproses field tertentu, maka sebaiknya Kita  menuliskan field yang ingin diakses saja, sehingga query Kita  menjadi SELECT field1, field2, field3 dan seterusnya (jangan pedulikan kode program yang menjadi lebih panjang!). Hal ini akan mengurangi beban lalu lintas jaringan dan lock pada table, terutama jika table tersebut memiliki banyak field dan berukuran besar.


Batasi ORDER BY
Penggunaan ORDER BY  yang berfungsi untuk mengurutkan data, ternyata memiliki konsekuensi menambah beban query, karena akan menambah satu proses lagi, yaitu proses sort.
Karena itu gunakan ORDER BY hanya jika benar-benar dibutuhkan oleh aplikasi Kita .
Atau jika dimungkinkan, Kita  dapat melakukan pengurutan pada sisi client dan tidak pada sisi server. Misalnya dengan menampung data terlebih dahulu pada komponen grid dan melakukan sortir pada grid tersebut sesuai kebutuhan pengguna.


Subquery Atau JOIN
Adakalanya sebuah instruksi dapat dituliskan dalam bentuk subquery atau perintah JOIN, disarankan Kita  memprioritaskan penggunaan JOIN karena dalam kasus yang umum akan menghasilkan performa yang lebih cepat.
Walaupun demikian, mengolah query merupakan suatu seni, selalu ada kemungkinan ternyata subquery bekerja lebih cepat dibandingkan JOIN, misalnya dalam kondisi penggunaan
JOIN yang terlalu banyak, ataupun logika query yang belum optimal.
Gunakan WHERE dalam SELECT
“Di mana ada gula di sana ada semut”. Untuk programer database, pepatah itu perlu dimodifi  kasi menjadi “di mana ada SELECT di sana ada WHERE”, untuk mengingatkan pentingnya klausa WHERE sebagai kondisi untuk menyaring record sehingga meminimalkan beban jaringan.
Saat sebuah table dengan jumlah data yang sangat besar diproses, juga terjadi proses lock terhadap table tersebut sehingga menyulitkan pengaksesan table yang bersangkutan oleh pengguna yang lain.
Bahkan jika Kita  bermaksud memanggil seluruh record, tetap menggunakan WHERE merupakan kebiasaan yang baik.
Jika Kita  telah menggunakan WHERE pada awal query, maka kapanpun Kita  ingin menambahkan kondisi tertentu, Kita  tinggal menyambung query tersebut dengan klausa AND diikuti kondisi yang diinginkan.
Tapi bagaimana menggunakan WHERE jika benar-benar tidak ada kondisi apapun? Kita  dapat menuliskan suatu kondisi yang pasti bernilai true, misalnya SELECT …. WHERE 1=1. Bahkan tools open source phpMyAdmin yang berfungsi untuk mena  ngani database MySQL selalu menyertakan default klausa WHERE 1 pada perintah SELECT, di mana angka 1 pada MySQL berarti nilai true.


Kecepatan Akses Operator
WHERE 1=1 dan WHERE 0 <> 1 sama-sama merupakan kondisi yang menghasilkan nilai true. Tetapi, dalam hal ini lebih baik Kita menggunakan WHERE 1=1 daripada WHERE 0 <> 1. Hal ini dikarenakan operator = diproses lebih cepat dibandingkan dengan operator <>.
Dari sisi kinerja, urutan operator yang diproses paling cepat adalah:
1. =
2. >, >=, <. <=
3. LIKE
4. <>
Tidak dalam setiap kondisi operator dapat disubtitusikan seperti contoh sederhana di atas, tetapi prioritaskanlah penggunaan operator yang tercepat.


Membatasi Jumlah Record
Bayangkan Kita  menampilkan isi sebuah table dengan menggunakan SELECT, dan ternyata table tersebut memiliki jutaan record yang sangat tidak diharapkan untuk tampil seluruhnya.
Skenario yang lebih buruk masih dapat terjadi, yaitu query tersebut diakses oleh ratusan pengguna lain dalam waktu bersamaan!
Untuk itu, Kita  perlu membatasi jumlah record yang berpotensi mengembalikan record dalam jumlah besar (kecuali memang benar-benar dibutuhkan), pada SQL Server, Kita  dapat menggunakan operator TOP di dalam perintah SELECT.
Contohnya SELECT TOP 100 nama…  akan menampilkan 100 record teratas field nama.
Jika menggunakan MySQL, Kita  dapat menggunakan LIMIT untuk keperluan yang sama.


Batasi Penggunaan Function
Gunakan fungsi-fungsi yang disediakan SQL seperlunya saja.
Sebagai contoh, jika Kita  menemukan query sebagai berikut: SELECT nama FROM tbl_teman WHERE ucase(nama) = ‘ABC’, nampak query tersebut ingin mencari record yang memiliki data berisi “abc”, fungsi ucase digunakan untuk mengubah isi field nama menjadi huruf besar dan dibandingkan dengan konstanta “ABC” untuk meyakinkan bahwa semua data “abc” akan tampil, walaupun dituliskan dengan huruf kecil, besar, ataupun kombinasinya.
Tetapi, cobalah mengganti query tersebut menjadi SELECT nama FROM tbl_teman WHERE nama = ‘ABC’, perhatikan query ini tidak menggunakan  function ucase. Apakah menghasilkan result yang sama dengan query pertama? Jika pengaturan database Kita  tidak case-sensitive (dan umumnya secara default memang tidak case-sensitive), maka hasil kedua query tersebut adalah sama. Artinya, dalam kasus ini Kita  sebenarnya tidak perlu menggunakan function ucase!


Baca dari Kiri ke Kanan
Query yang Kita  tulis akan diproses dari kiri ke kanan, misalkan terdapat query WHERE kondisi1 AND kondisi2 AND kondisi3, maka kondisi1 akan terlebih dahulu dievaluasi, lalu kemudian kondisi2, kondisi3, dan seterusnya. Tentunya dengan asumsi tidak ada kondisi yang diprioritaskan/dikelompokkan dengan menggunakan tKita  kurung.
Logika operator AND akan langsung menghasilkan nilai false saat ditemukan salah satu kondisi false, maka letakkan kondisi yang paling mungkin memiliki nilai false pada posisi paling kiri. Hal ini dimaksudkan agar SQL tidak perlu lagi mengevaluasi kondisi berikutnya saat menemukan salah satu kondisi telah bernilai false.
Jika Kita  bingung memilih kondisi mana yang layak menempati posisi terkiri karena kemungkinan falsenya sama atau tidak bisa diprediksi, pilih kondisi yang lebih sederhana untuk diproses.


Gambar dalam Database
Database memang tidak hanya diperuntukkan sebagai penyimpanan teks saja, tetapi dapat juga berupa gambar. Kalau pepatah mengatakan sebuah gambar bermakna sejuta kata, tidak berarti kita harus menyediakan tempat penyimpanan seukuran sejuta kata untuk menampung satu gambar! Akan lebih baik bagi kinerja database jika Kita  hanya menyimpan  link ataulokasi gambar di dalam database, dibandingkan menyimpan fisik gambar tersebut.
Kecuali jika Kita  tidak memiliki pilihan lain, misalnya karena alasan keamanan atau tidak tersedianya tempat penyimpanan lain untuk gambar Kita  selain di dalam database.
Tetapi, jelas jika Kita  dapat memisahkan gambar secara fisik dari database, maka ukuran dan beban database akan relatif berkurang drastis, proses seperti back-up dan migrasi akan lebih mudah dilakukan.


Pengukuran Kinerja
Terdapat  tools optimizer yang bervariasi untuk tiap RDBMS, Kita  dapat menggunakannya sebagai panduan untuk meningkatkan kinerja query, di mana Kita  dapat mengetahui berapa lama waktu eksekusi atau operasi apa saja yang dilakukan sebuah query.
Jika Kita  menemukan sebuah query tampak tidak optimal, berusahalah menulis ulang query tersebut dengan teknik dan metode yang lebih baik. Semakin banyak query yang dapat dioptimasi, akan semakin baik kinerja aplikasi Kita . Terutama saat frekuensi pemakaian query tersebut relatif tinggi.


Back-up
Buatlah back-up otomatis secara periodik, sebaiknya tes dan simulasikan prosedur restore database dan perhitungkan waktu yang diperlukan untuk membuat sistem pulih kembali jika terjadi sesuatu yang tidak diharapkan pada database.
Lakukan proses back-up pada waktu di mana aktivitas relatif rendah agar tidak mengganggu kegiatan operasional.


Banyak Jalan Menuju Roma
Berikan satu masalah pada beberapa programer, maka Kita  mungkin akan mendapatkan beberapa solusi yang berbedabeda. Banyak alternatif yang dapat diciptakan untuk menghasilkan sesuatu, tetapi tentunya kita menginginkan alternatif yang terbaik.
Karena itu, jangan ragu mencoba menuliskan ulang query Kita  dengan cara lain jika Kita  melihat kemungkinan peningkatan kinerja, contohnya pada potongan query berikut:
WHERE SUBSTRING(nama,1,1) =’b’
Query di atas akan mengambil record dengan kondisi karakter pertama kolom nama adalah “b”, sehingga akan tampil isi record seperti “Budi”, “Badu”, “Benny” dan seterusnya. Cara lain untuk menghasilkan record yang sama adalah sebagai berikut:
WHERE nama LIKE ‘b%’
Hasil yang ditampilkan kedua query tersebut akan sama, tetapi performa yang dihasilkan (terutama untuk record berukuran besar) akan berbeda.  Umumnya kondisi LIKE akan bekerja dengan lebih cepat dibandingkan function SUBSTRING.
Contoh lain yang lebih kompleks adalah seperti query beri-kut:
SELECT NIP, nama FROM tbl_pegawai WHERE dept = ‘IT’ OR kota
= ‘jakarta’ OR divisi = ‘programer’
Perhatikan query di atas memiliki tiga kondisi yang dipisahkan oleh klausa OR. Alternatif lain adalah dengan menuliskan query sebagai berikut:
SELECT NIP, nama FROM tbl_pegawai WHERE dept = ‘IT’
UNION ALL
SELECT NIP, nama FROM tbl_pegawai WHERE kota = ‘jakarta’
UNION ALL
SELECT NIP, nama FROM tbl_pegawai WHERE divisi = ‘programer’
Walaupun penulisan query menjadi lebih panjang, bisa jadi al-ternatif ini akan lebih baik. Mengapa? Dengan asumsi field dept memiliki index, sementara field kota dan divisi tidak diindex, query pertama tidak akan menggunakan index dan melakukan table scan. Berbeda dengan query kedua, index akan tetap dilakukan pada sebagian query sehingga akan menghasilkan kinerja yang relatif lebih baik.
Ah… Beda Tipis Saja!
Pastinya masih banyak terdapat teknik lain yang tidak akan dapat dibahas semuanya dalam artikel ini. Di antara (atau mungkin semua) teknik optimasi yang dibahas di atas, mungkin Kita  akan menemukan bahwa setelah diuji dengan data sampel maka kinerja sebelum dan sesudah optimasi ternyata sama sekali tidak signifikan, beda tipis, atau tidak ada bedanya sama sekali!
Memang benar, dengan spesifi  kasi hardware yang semakin meningkat, data yang relatif kecil, dan alur yang sederhana, Kita  mungkin tidak akan mendapatkan perbedaan yang signifikan.
LEBIH LANJUT

• http://blog.sqlauthority.com/
• http://blogs.msdn.com/queryoptteam/
• http://www.sql-server-performance.com
• 
  
• Sumber: http://balebat.wordpress.com/2009/06/08/optimasi-sql/

Pengukuran Perangkat Lunak Menggunakan Metrik Size-Oriented dan Metrik Function Oriented

PENGANTAR:
Pengukuran adalah suatu hal pokok bagi disiplin perekayasaan(engineering), tidak terkecuali pada perekayasaan perangkat lunak atau software. Jangkauan luas pengukuran pada perangkat lunak komputer disebut metrik perangkat lunak.
Tujuan diterapkannya pengukuran pada proses perangkat lunak adalah untuk mengembangkan perangkat lunak itu sendiri dengan dasar yang kontinu.
Pengukuran software dalam konteks manajemen software difokuskan pada produktivitas dan metrik kualitas (pengukuran output perkembangan software sebagai fungsi usaha dan waktu yang diaplikasikan serta pengukuran “kesesuaian pemakaian” dari produk kerja yang dihasilkan).

1. PENGUKURAN, METRIK, DAN INDIKATOR

Dalam konteks rekayasa perangkat lunak, mengukur (measure) mengindikasikan kuantitatif dari ukuran atribut sebuah proses atau produk. Pengukuran (measurement) adalah kegiatan menentukan sebuah measure (pengukuran). Dan definisi metriks menurut IEEE adalah “ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu”.
Pengukuran telah ada jika suatu data-data tunggal telah dikumpulkan (misal: jumlah kesalahan yang ditemukan pada kajian sebuah modul tunggal). Metrik perangkat lunak menghubungkan pengukuran-pengukuran individu dengan banyak cara, misal rata-rata dari jumlah kesalahan yang ditemukan pada setiap kajian.

Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metrik menjadi sebuah indikator, yaitu sebuah metrik atau kombinasi metrik yang memberikan pengetahuan dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk itu sendiri. Fungsinya adalah memberi pengetahuan pada manajer proyek atau perekayasa perangkat lunak untuk menyesuaikan proses, proyek, dan produk agar menjadi lebih baik.

2. PENGUKURAN PERANGKAT LUNAK

Pengukuran langsung dari produk berkaitan dengan deretan kode, kecepatan eksekusi, ukuran memori, dan cacat yang dilaporkan pada suatu periode tertentu. Sedangkan pengukuran tidak langsung dari produk adalah tentang fungsionalitas, kualitas, kompleksitas, efisiensi, realibilitas, kemampuan pemeliharaan, dsb.Dalam kenyataannya, pengukuran perangkat lunak secara objektif akan sulit dilakukan secara langsung karena ada pengaruh-pengaruh seperti individu dalam tim pengukuran, atau tingkat kompleksitas proyek.
Tetapi jika pengukuran dinormalisasi, maka mungkin akan dapat didapatkan metrik perangkat lunak yang memungkinkan perbandingan dengan rata-rata organisasional yang lebih besar.

2.1 METRIK SIZE ORIENTED

Parameternya adalah ”ukuran” dari software yang dihasilkan. Dapat dilakukan jika ada record atau catatan dari organisasi. Perlu diperhatikan bahwa yang record yang diperlukan adalah keseluruhan aktivitas rekayasa perangkat lunak. Misalnya tabel dibawah ini adalah pengumpulan dari data-data record yang ada dari sebuah organisasi:

Dimana LOC (line of code) menunjukkan jumlah baris kode yang dibuat pada masing-masing proyek, misalnya pada kolom pertama, proyek aplha dibuat dengan 12100 baris kode dalam 365 halaman, dikembangakan dengan usaha 24 orang per bulan dengan biaya $168000. Lalu ditemukan kesalahan sebanyak 134 pada proyek sebelum direlease, 29 cacat setelah direlease pada pelanggan, dan ada 3 orang yang bekerja pada pengembangan proyek perangkat lunak alpha.

Untuk pengembangan dari metrik ini, dapat dibuat metrik size oriented baru yang sederhana untuk tiap proyek, misal: kesalahan per baris kode (dihitung ribuan), cacat per baris kode (ribuan), dokumentasi per baris kode (ribuan), kesalahan per usaha, baris kode per usaha, biaya per halaman dokumentasi, dsb.

Metrik ini tidak dapat diterima secara universal karena adanya kontroversi pada penggunaan baris kode sebagai titik ukur. Sebagian yang setuju pada pengukuran LOC menganggap bahwa LOC adalah suatu bukti real dari apa yang dilakukan oleh perekayasa perangkat lunak (dalam konteks ini membuktikan berapa banyak baris program yang ditulis oleh seorang programmer – comment yang ada).

Sedangkan sebagian yang tidak setuju bahwa LOC dijadikan suatu tolak ukur kebanyakan disebabkan alasan ambiguitas dari cara menghitung LOC itu sendiri. Dalam masa-masa awal bahasa pemrograman Assembly, hal ini tidak menjadi suatu masalah karena dalam 1 baris aktual program merupakan 1 baris instruksi, tetapi dalam bahasa pemrograman tingkat tinggi, dimana pada masing-masing bahasa, untuk menyelesaikan suatu masalah dengan algoritma yang sama pun LOC nya sudah berbeda-beda. Bahkan dalam satu bahasa pemrograman yang sama, untuk menyelesaikan masalah yang sama, LOC nya bisa berbeda jauh tergantung dari algoritma yang digunakan. Hal ini yang membuat banyak sekali kontroversi mengenai LOC sebagai tolak ukur dari sebuah software.

2.2 METRIK FUNCTION ORIENTED

Normalisasi dilakukan pada fungsionalitas pada aplikasi, tetapi untuk melakukan hal ini, fungsionalitas harus diukur dengan pengukuran langsung yang lain karena fungsionalitas tidak dapat diukur secara langsung. Maka pengukuran dapat dilakukan dengan pengukuran function point. Function point didapat dari penarikan hubungan empiris berdasarkan pengukuran domain informasi software dan perkiraan kompleksitas software.
Domain informasi yang biasa digunakan ada 5 karakteristik, yaitu:
· jumlah input pemakai: setiap input pemakai yang memberikan data yang berorientasi pada aplikasi yang jelas pada perangkat lunak (harus dibedakan dari penelitian yang dihitung secara terpisah) misal: tipe transaksi.
· jumlah output pemakai: setiap output pemakai yang memberikan informasi yang berorientasi pada aplikasi kepada pemakai. Pada konteks ini output mengacu pada laporan, layar, tampilan kesalahan, dsb. Jenis data individual pada laporan tidak dihitung terpisah. misal: report type.
· jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk output online.
· jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file terpisah).
· jumlah interface eksternal: semua interface yang dapat dibaca oleh mesin yang digunakan untuk memindahkan informasi ke sistem yang lain

Sekali data telah dikumpulkan, maka nilai kompleksitas dihubungkan dengan masing-masing penghitungan dengan tabel perhitungan sebagai berikut:
Faktor pembobotan

Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan tidak dapat diubah-ubah, tetapi dalam penentuan kriteria suatu perangkat lunak pada salah satu parameter pengukuran adalah sederhana, rata-rata atau kompleks ditentukan oleh organisasi atau perkeyasa perangkat lunak yang melakukan penghitungan itu sendiri. Tetapi meskipun begitu perkiraan kompleksitas tetap bersifat subyektif.

Untuk menghitung function point (FP) dapat digunakan hubungan sbb:
FP = jumlah total x [0,65 + 0,01 x Fi]
dimana jumlah total adalah nilai yang kita dapatkan pada tabel perhitungan di atas.

Sedangkan Fi dapat dihitung dari perhitungan sebagai berikut:
· Pertama-tama kita diberi 14 buah karakteristik dari suatu perangkat sebagai berikut:
1. Data communications
2. Distributed functions
3. Performance
4. Heavily used configuration
5. Transaction rate
6. Online data entry
7. End-user efficiency
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitation of change
Pada setiap karakteristik tersebut diberi bobot dari nilai 0 sampai 5 dengan asumsi nilai sebagai berikut:
0. Tidak berpengaruh
1. Insidental
2. Moderat
3. Rata-rata
4. Signifikan
5. Essential

Setelah setiap karakteristik diberi bobot masing-masing, lalu bobot-bobot dari setiap karakteristik ini dijumlahkan (jadi minimum 0 dan maksimal 70) dan kita akan mendapatkan nilai Fi. Setelah mendapatkan nilai Fi maka kita bisa menghitung nilai FP dengan rumus di yang sudah ada di atas.
Setelah kita mendapatkan nilai FP, maka kita dapat menggunakannya dengan cara analog dengan LOC untuk menormalisasi pengukuran produktivitas, kualitas perangkat lunak, serta atribut-atribut yang lain seperti:

· kesalahan per FP
· cacat per FP
· $ per FP
· halaman dokumentasi per FP
· FP per person-month
· dsb
(dimana untuk mendapatkan data-data untuk kesalahan, cacat, dolar, dsb dapat diambil dari data-data pada tabel record pada metrik size-oriented).

Contoh:

Pada proyek alpha (tabel record metrik size oriented) sudah dihitung bahwa jumlah input pemakainya ada 18 buah, jumlah output pemakai: 6 buah, jumlah penyelidikan pemakai 22 buah, jumlah file 45 buah, jumlah interface eksternal 20 buah, dengan asumsi bahwa jumlah input pemakai rata-rata, jumlah output pemakai sederhana, jumlah penyelidikan pemakai rata-rata, jumlah file kompleks, jumlah interface eksternal sederhana. Semua karakteristik pada perangkat lunak ini moderat. Hitung $ per FP nya!

Jawab:

jumlah total = (18 x 4) + (6 x 4) + (22 x 4) + (45 x 15) + (20 x 6) = 979
Fi = 14 x 2 = 28
FP = 979 x (0,65 + (0,01 x 28)) = 910,47
$ pada proyek alpha: 168000
$ per FP = 168000 / 910,47 = $184,52

Hasil dari contoh kasus diatas masih berupa suatu angka mentah, untuk dapat dilihat apakah angka ini termasuk baik atau tidak harus diperbandingkan dengan perhitungan lain, misalnya $ per FP dari proyek beta atau gamma, atau proyek dari organisasi lain.

Sebenarnya banyak sekali metrik-metrik yang digunakan untuk mengukur perangkat lunak, misalnya metrik FP yang diperluas (biasanya diaplikasikan dalam dunia bisnis) tetapi belum sempat dibahas disini.

Penulis:
Arief Martoyo
5105100139

sumber: http://rpl07.wordpress.com/2007/06/21/pengukuran-perangkat-lunak-menggunakan-metrik-size-oriented-dan-metrik-function-oriented-oleh-arif-m-5105-100-139/

Posting Menggunakan Email

Kegiatan blogging sangat flexibel sekali, bisa menggunakan email sebagai sarana posting, hal ini akan sangat membantu pengguna blog yang tidak memiliki cukup waktu untuk sekedar masuk ke dalam halaman blogger atau melakukan penghematan pengeluaran karena menggunakan koneksi dial-up.

PERANCANGAN BASISDATA

Data, Informasi dan Basis Data

Data, Informasi dan Basis Data

Data merupakan fakta mengenai suatu objek seperti manusia, benda, peristiwa, konsep, keadaan dan sebagainya yang dapat dicatat dan mempunyai arti secara implisit. Data dapat dinyatakan dalam bentuk angka, karakter atau simbol, sehingga bila data dikumpulkan dan saling berhubungan maka dikenal dengan istilah basis data (database) [Ramez2000]. Sedangkan menurut George Tsu-der Chou basis data merupakan kumpulan informasi bermanfaat yang diorganisasikan ke dalam aturan yang khusus. Informasi ini adalah data yang telah diorganisasikan ke dalam bentuk yang sesuai dengan kebutuhan seseorang [Abdul1999]. Menurut Encyclopedia of Computer Science and Engineer, para ilmuwan di bidang informasi menerima definisi standar informasi yaitu data yang digunakan dalam pengambilan keputusan.

Definisi lain dari basis data menurut Fabbri dan Schwab adalah sistem berkas terpadu yang dirancang terutama untuk meminimalkan duplikasi data.

Menurut Ramez Elmasri mendefinisikan basis data lebih dibatasi pada arti implisit yang khusus, yaitu:

a. Basis data merupakan penyajian suatu aspek dari dunia nyata (real world).

b. Basis data merupakan kumpulan data dari berbagai sumber yang secara logika mempunyai arti implisit.    

    Sehingga data yang terkumpul secara acak dan tanpa mempunyai arti, tidak dapat disebut basis data.

c. Basis data perlu dirancang, dibangun dan data dikumpulkan untuk suatu tujuan. Basis data dapat digunakan  

    oleh beberapa user dan beberapa aplikasi yang sesuai dengan kepentingan user.

Dari beberapa definisi-definisi tersebut, dapat dikatakan bahwa basis data memounyai berbagai sumber data dalam pengumpulan data, bervariasi derajat interaksi kejadian dari dunia nyata, dirancang dan dibangun agar dapat digunakan oleh beberapa user untuk berbagai kepentingan [Waliyanto2000].

Hirarki Data

Data diorganisasikan kedalam bentuk elemen data (field), rekaman (record), dan berkas (file). Definisi dari ketiganya adalah sebagai berikut:

Elemen data adalah satuan data terkecil yang tidak dapat dipecah lagi menjadi unit lain yang bermakna. Misalnya data siswa terdiri dari NIS, Nama, Alamat, Telepon atau Jenis Kelamin.

Rekaman merupakan gabungan sejumlah elemen data yang saling terkait. Istilah lain dari rekaman adalah baris atau tupel.

Berkas adalah himpunan seluruh rekaman yang bertipe sama.

Sistem Basis Data

[Waliyanto2000] Gabungan antara basis data dan perangkat lunak SMBD (Sistem Manajemen Basis Data) termasuk di dalamnya program aplikasi yang dibuat dan bekerja dalam satu sistem disebut dengan Sistem Basis Data.

C. J. Date menyatakan bahwa sistem basis data dapat dianggap sebagai tempat untuk sekumpulan berkas data yang terkomputerisasi dengan tujuan untuk memelihara informasi dan membuat informasi tersebut tersedia saat dibutuhkan.

Data Base Management System (DBMS)/Sistem Manajemen Basis Data (SMB)

DBMS dapat diartikan sebagai program komputer yang digunakan untuk memasukkan, mengubah, menghapus, memodifikasi dan memperoleh data/informasi dengan praktis dan efisien. Kelebihan dari DBMS antara lain adalah:

• Kepraktisan. DBMS menyediakan media penyimpan permanen yang berukuran kecil namun banyak 

   menyimpan data jika dibandingkan dengan menggunakan kertas.

• Kecepatan. Komputer dapat mencari dan menampilkan informasi yang dibutuhkan dengan cepat.

• Mengurangi kejemuan. Pekerjaan yang berulang-ulang dapat menimbulkan kebosanan bagi manusia, 

   sedangkan mesin tidak merasakannya.

• Update to date. Informasi yang tersedia selalu berubah dan akurat setiap.

[Waliyanto2000] Keuntungan-keuntungan dalam penggunaan DBMS antara lain adalah:

a. Pemusatan kontrol data. Dengan satu DBMS di bawah kontrol satu orang atau kelkompok dapat  

    menjamin terpeliharanya standar kualitas data dan keamanan batas penggunaannya serta dapat menetralkan 

    konflik yang terjadi dalam persyaratan data dan integritas data dapat terjaga.

b. Pemakaian data bersama (Shared Data). Informasi yang ada dalam basis data dapat digunakan lebih efektif 

    dengan pemakaian beberapa user dengan kontrol data yang terjaga.

c. Data yang bebas (independent). Program aplikasi terpisah dengan data yang disimpan dalam komputer.

d. Kemudahan dalam pembuatan program aplikasi baru.

e. Pemakaian secara langsung. DBMS menyediakan interface yang memudahkan pengguna dalam mengolah 

    data.

f.  Data yang berlebihan dapat dikontrol. Data yang dimasukkan dapat terjadi kerangkapan (redudant), untuk 

    itu DBMS berfungsi untuk menurunkan tingkat redudancy dan pengelolaan proses pembaruan data.

g. Pandangan user (user view). Ada kemungkinan basis data yang diakses adalah sama, maka DBMS mampu 

   mengatur interface yang berbeda dan disesuaikan dengan pemahaman tiap user terhadap basis data menurut 

    kebutuhan.

Kelemahan-kelemahan DBMS antara lain:

a. Biaya. Kebutuhan untuk medapatkan perangkat lunak dan perangkat keras yang tepat cukup mahal,  

    termasuk biaya pemeliharaan dan sumber daya manusia yang mengelola basis data tersebut.

b. Sangat kompleks. Sistem basis data lebih kompleks dibandingkan dengan proses berkas, sehingga dapat 

    mudah terjadinya kesalahan dan semakin sulit dalam pemeliharaan data.

c. Resiko data yang terpusat. Data yang terpusat dalam satu lokasi dapat beresiko kehilangan data selama 

    proses aplikasi.

Model Data

Model data dapat dikelompokkan berdasarkan konsep pembuatan deskripsi struktur basis data, yaitu:

a. Model data konsepsual (high level) menyajikan konsep tentang bagaiman user memandang atau 

    memperlakukan data. Dalam model ini dikenalkan tiga konsep penyajian data yaitu:

    • Entity (entitas) merupakan penyajian obyek, kejadian atau konsep dunia nyata yang keberadaannya 

      secara eksplisit didefinisikan dan disimpan dalam basis data, contohnya Mahasiswa, Matakuliah, Dosen, 

      Nilai dan lain sebagainya.

    • Atribute (atribut) adalah keterangan-keterangan yang menjelaskan karakteristik dari suatu entitas seperti 

      NIM, Nama, Fakultas, Jurusan untuk entitas Mahasiswa.

    • Relationship (hubungan) merupakan hubungan atau interaksi antara satu entitas dengan yang lainnya, 

       misalnya entitas pelanggan berhubungan dengan entitas barang yang dibelinya.

b. Model data fiskal (low level) merupakan konsep bagaimana deskripsi detail data disimpan ke dalam 

    komputer dengan menyajikan informasi tentang format rekaman, urutan rekaman, dan jalur pengaksesan  

    data yang dapat membuat pemcarian rekaman data lebih efisien.

c. Model data implementasi (representational) merupakan konsep deskripsi data disimpan dalam komputer 

   dengan menyembunyikan sebagian detail deskripsi data sehingga para user mendapat gambaran global  

    bagaimana data disimpan dalam komputer. Model ini merupakan konsep model data yang digunakan oleh 

    model hirarki, jaringan dan relasional.

Skema dan Instan Basis Data

Skema basis data merupakan deskripsi dari basis data yang spesifikasinya ditentukan dalam tahap perancangan namun tidak terlalu diharapkan diubah setiap saat. Penggambaran skema umumnya hanya berisi sebagian dari deatil deskripsi basis data.

Sekelompok data yang tersusun dalam satu baris rekaman (record/tuple) dan tersimpan dalam basis data disebut dengan instansi (instance) atau kejadian (occurences).

Arsitektur DBMS

Arsitektur ini dikenal dengan nama arsitektur tiga skema (three-schema architecture) dimana fungsi ini untuk memisahkan antara basis data fisik dengan program aplikasi user. Skema-skema tersebut adalah sebagai berikut:

a. Level internal merupakan skema internal yang memuat deskripsi struktur penyimpanan basis data dan 

    menggunakan model data fisikal serta mendefinisikan secara detail penyimpanan data dalam basis data, 

    serta jalur pengaksesan data.

b. Level konsepsual adalah skema yang memuat deskripsi struktur basis data secara keseluruhan untuk semua 

    pemakai. Skema ini hanya memuat deskripsi tentang entitas, atribut, hubungan dan batasan, tanpa memuat 

    deskripsi data secara detail.

c. Level eksternal merupakan skema eksternal (user view) yang mendefinisikan pandangan data terhadap 

    sekelompok user (local view) dengan menyembunyikan data lain yang tidak diperlukan oleh kelompok user 

    tersebut.

Keuntungan dari arsitektur ini antara lain:

a. Perubahan skema konsepsual, yaitu adanya perubahan dalam skema konsepsual contohnya penambahan 

    suatu item data tidak akan berpengaruh pada program aplikasi. Tetapi jika skema eksternal tidak sesuai 

    lagi dengan skema konsepsual yang baru maka program aplikasi harus disesuaikan juga.

b. Perubahan skema internal. Pemisahan antara skema eksternal dan skema internal berfungsi untuk menjaga 

    bila terjadi perubahan skema internal, misalnya ada penambahan “pointer” pada rekaman tidak 

    memerlukan perubahan pada aplikasi.

c. Perubahan skema eksternal. Adanya penambahan skema eksternal atau pembuatan skema eksternal baru 

    tidak akan berpengaruh pada aplikasi yang ada selama aplikasi tersebut tidak mengakses data berdasarkan 

    skema yang baru.

Komponen DBMS

Komponen-komponen DBMS (Howe,1991) terdiri dari:

• Interface, yang didalamnya terdapat bahasa manipulasi data (data manipulation language)

• Bahasa definisi data (data definition language) untuk skema eksternal, skema konsepsual dan skema internal.

• Sistem kontrol basis data (Database Control System) yang mengakses basis data karena adanya perintah 

  dari bahasa manipulasi data.

Contoh bahasa menggunakan komponen-komponen tersebut adalah SQL (Structured Query Language). SQL merupakan bahasa standar yang digunakan oleh kebanykan aplikasi-aplikasi DBMS.

Klasifikasi DBMS

Sistem Basisi Data dapat diklasifikasikan menjadi tiga bagian, yang terdiri dari:

a. Klasifikasi berdasarkan model data. Klasifikasi ini terdiri dari model data hirarki, model data jaringan, 

    model data relasional.

   1. Model data hirarki

       Dalam model ini, data disusun menurut struktur pohon yang merupakan bentuk lain dari abstraksi data 

       untuk basis data akademi. Pada puncak hirarki diesbut dengan akar (root). Tiap entitas tingkat atas 

       (parent) mempunyai satu atau lebih sub-entitas (children) sehingga setiap entitas hanya boleh mempunyai 

       satu induk, tetapi dapat mempunyai banyak anak. 

       Pada mode data hirarki, hubungan antar entitas dinyatakan dalam satu-banyak (one to many) atau satu-

       satu (one to one). Dalam satu Universitas terdapat banyak Fakultas dan setiap Fakultas terdapat banyak 

       Dosen atau banyak Mahasiswa, dan seterusnya. Tanda panah menunjukkan derajat keterhubungan 

       “banyak”.

       Untuk menampilkan semua mata kuliah pada Fakultas tertentu harus dilakukan dalam dua tahap. Yang 

       pertama adalah menampilkan rekaman semua Dosen yang mengajar di Fakultas tersebut, kemudian baru 

       mata kuliah yang dipegang oleh para Dosen. Dalam hal ini penampilan data terlihat kurang efisien, sebab 

       menggunakan entitas perantara (dosen) yang harus ditampilkan juga. Dikarenakan kunci data yang 

       digunakan untuk menghubungkan antar entitas diberi kode dalam struktur data, maka untuk jumlah entitas 

       perantara yang sedikit masih dapat dikatakan efisien.

       Kelemahan lain pada model data hirarki adalah tidak dapat melakukan pencarian data pada field. 

       Misalnya dalam entitas mata ki\uliha tida pat ditampilkan hanya mata kuliah dengan jumlah SKS tertentu,  

       sebab field “Jumlah SKS” bukan sebagai kunci data. Hal ini masih dapat dilakukan dengan mengubah 

       struktur data dengan memberi hubungan khusus yang digunakan untuk mengubah struktur database. 

       Kelebihan model ini adalah sangat mudah dipahami dan mudah dalam pembaharuan data 

       [Waliyanto2000].

2. Model data Jaringan

Dalam model ini setiap entitas dapat mempunyai banyak induk dan banyak anak. Pada gambar menunjukkan entitas mata kuliah mempunyai dua induk, yaitu langsung berhubungan dengan Fakultas dan Dosen.

Dalam model ini lebih sedikit terdapat data rangkap, namun lebih banyak terdapat hubungan antar entitas, sehingga akan menambah informasi hubungan yang harus disimpan dalam database. hal ini akan menambah volume dan kerumitan dalam penyimpanan berkas data.

3. Model data Relasional

Dalam model ini setiap field dapat dijadikan kunci data. Data rekaman disusun dari nilai yang berhubungan (record). Baris-baris ini akan membentuk tabel yang umunya tersimpan dalam satu berkas (file).

Dengan menggunakan model ini, pencarian field dari suatu tabel atau banyak tabel dapat dilakukan dengan cepat. Pencarian atribut yang berhubungan pada tabel yang berbeda dapat dilakukan dengan menghubungkan terlebih dahulu tabel-tabel tersebut dengan menggunakan atribut yang sama (joint operation).

Keuntungan yang didapat dengan menggunakan model ini adalah sebagai berikut [Waliyanto2000]:

• Model ini lebih luwes karena nilai data dalam tabel tidak ada pembatasan dalam berbagai proses pencarian data.

• Model ini mempunyai latar belakang teori matematika.

• Pengorganisasian model relasional sangat sederhana, sehingga mudah dipahami.

• Basis data yang sama biasanya dapat disajikan dengan lebih sedikit terjadi data rangkap (redudancy data).

Sedangkan beberapa kelemahan model ini adalah [Waliyanto2000]:

• Lebih sulit dalam implementasinya terutama untuk data dengan jumlah yang besar dan tingkat kompleksitasnya tinggi.

• Proses pencarian informasi lebih lambat, karena beberapa tabel tidak dihubungkan secara fisik. Dalam manipulasi data yang menggunakan beberapa tabel akan memerlukan waktu yang lama, karena tabel-tabel harus dihubungkan terlebih dahulu.

b. Klasifkasi berdasarkan lokasi penyimpanan data, yaitu DBMS terpusat dan DBMS terdistribusi. Dalam DBMS terpusat basis data disimpan dalam satu komputer media penyimpan sehingga pengguuna sistem mengakses data dari pusat. DBMS terdistribusi, basis data tersebar pada penyimpanan tiap terminal pengguna (client). Antar pengguna dapat mengakses data secara langsung tanpa perlu melalui pusat penyimpanan. DBMS ini memerlukan sistem kontrol yang rumit.

c. Klasifikasi berdasarkan tujuan DBMS digunakan yaitu tujuan umum (general purpose) dan tujuan khusus (special purpose). Untuk tujuan umum dapat digunakan untuk berbagai tujuan dengan memperlakukan data sama menurut penggunaannya contoh aplikasinya adalah DBASE,ORACLE, FOXBASE dan sebagainya.  DBMS tujuan khusus dirancang dan digunakan untuk keperluan tertentu, sebagai contoh pengelolaan data karyawan pada perusahaan Asuransi.

Pengembangan Database

Database diproses oleh DBMS untuk digunakan oleh pengembang maupun pengguna, yang mengakses DBMS secara langsung atau tidak langsung melalui program-program aplikasi. Database terdiri dari empat elemen utama yaitu data pengguna, metadata, indeks dan metadata aplikasi [David2002].

Data Pengguna

Hampir semua database me-representasikan data pengguna sebagai relasi dengan menganggapnya sebagai tabel data. Kolom dalam tabel berisi field-field atau atribut dan baris tabel berisi record/tuple (rekaman) untuk keterangan entitas dalam lingkungan bisnis. Tidak semua relasi diperlukan, beberapa relasi lebih baik distrukturkan dengan proses normalisasi. 

Relasi ini dapat digambarkan dengan bentuk hubungan antara pelajar dengan guru sebagai berikut:

Tabel 1-1 Relasi Pelajar dengan Guru (R1)

Struktur relasi tersebut dapat terjadi beberapa masalah, misalnya jika guru Dadang mengganti nomor telepon maka tiga record yang terdapat guru Dadang diatas harus diganti juga. Untuk itu lebih baik jika struktur relasi diubah menjadi dua relasi seperti di bawah ini:

Tabel 1-2 Hubungan antara R1 dan R2

Dari relasi diatas akan pengubahan data hanya dilakukan pada relasi kedua.

Metadata

Penjelasan struktur dari suatu tabel disebut dengan metadata dan terkadang disebut dengan system tables. Bentuk dari metada dapat digambarkan seperti dibawah ini yang terdiri dua tabel. Tabel pertama berisi daftar tabel-tabel di dalam suatu database sedangkan tabel yang kedua berisi daftar kolom-kolom pada suatu tabel.

Tabel 1-3 Tabel SysTable

Tabel 1-4 Tabel SysColumns

Indeks

Tipe database ini digunakan untuk meningkatkan kinerja dan akses suatu database. Terkadang tipe 

data ini disebut dengan overhead data, terdiri dari prinsip-prinsip indeks serta beberapa penggunaan 

struktur data link list. Di bawah ini contoh pengguanan dua buah indeks dari tabel Mahasiswa:

Indek tidak hanya digunakan untuk pengurutan, tetapi digunakan juga untuk mengakses cepat ke 

database terutama pencarian data. Apbila suatu tabel contuhnya tabel Mahasiswa, mengalami 

pengubahan data (penambahan/pengubahan/penghapusan) maka tabel indeks mengalami 

pengubahan juga.

Application Metadata

Application metadata digunakan untuk menyimpan struktur dan format dari user forms, report, queries 

dan komponen-komponen aplikasi lainnya. 

Konsep Dasar Tabel

Tabel merupakan blok dasar yang paling umum digunakan dalam sistem basis data, atau disebut juga  

dengan relasi. Komponen tabel terdiri dari beberapa kolom yang ditandai dengan jenis atribut. 

Perpotongan antara baris dan kolom disebut nilai atribut. Tujuan penggunaan tabel adalah untuk 

menyederhanakan logika pandangan terhadap data. Beberapa kententuan-ketentuan dalam 

penyusunan sebuah tabel adalah sebagai berikut [Waliyanto2000]:

a. Urutan baris diabaikan, sehingga pertukaran baris tidak berpengaruh pada isi informasi tabel.

b. Urutan kolom diabaikan serta identifikasi kolom dibedakan dengan jenis atribut.

c. Tiap perpotongan antara baris dan kolom berisi atribut tunggal

d. Tiap baris dalam tabel harud dibedakan, sehingga tidak ada dua baris atau lebih dalam tabel 

mempunyai nilai atribut yang sama secara keseluruhan.

Tabel yang memenuhi ketentuan ini disebut dengan tabel normal, jika belum maka dilakukan proses 

normalisasi.

Salah satu keuntungan menggunakan basis data adalah konsistensi data selalu terjaga dengan 

menghindari adanya data rangkap (redudant data). Perbedaan antara data rangkap dan data duplikat 

adalah duplikasi data terjadi bila satu atribut mempunyai dua atau lebih nilai yang sama, sedangkan 

data rangkap adalah bila satu atribut mempunyai dua atau lebih nilai yang sama, namun bilai salah 

satu nilai dihapus, maka tidak ada informasi yang hilang, sehingga duplikasi data ini tidak perlu ada. 

Untuk lebih jelasnya lihat dua tabel berikut:

Pada tabel 1.8 terjadi duplikasi data pada atribut NamaGuru, andaikan baris pertama pada atribut 

NamaGuru dihilangkan maka informasi untuk atribut NamaPelajar baris pertama akan hilang, 

sedangkan pada tabel 1.9 dapat terlihat bahwa kalau atribut TeleponGuru dari baris pertama 

dihilangkan maka informasi ini masih dapat diketahui melalui atribut NamaGuru pada baris kedua, 

mengapa?

Salah satu syarat tabel normal adalah setiap atribut harus mempunyai nilai tunggal untuk tiap barisnya. 

Di bawah ini contoh dari suatu tabel yang mempunyai atribut bernilai ganda.

Dalam tabel di atas terdapat nilai atribut ganda pada kolom Gelar. Hal ini berakibat pengurutan data 

hanya dapat dilakukan berdasarkan kolom NIP dan Nama. Untuk menghilangkan nilai ganda tersebut, 

hal yang paling mudah dilakukan adalah membuat pengisian nilai atribut vertikal namun dapat

berakibat kerangkapan data, seperti di bawah ini.

Solusi yang teapat untuk menghilangkan kerangkapan data tersebut adalah dengan membagi tabel 

menjadi dua bagian yang saling terhubung dengan elemen penghubung salah satu atributnya. 

Perhatikan tabel-tabel di bawah ini:

Dengan cara ini dapat mempermudah dalam proses normalisasi berikutnya. Dalam penyusunan 

aturan data perlu dipahami tentang determinan dan identitas. Jika sebuah tabel memiliki atribut A, B, 

dan C, sedangkan A menjadi penentu B atau sebaliknya B ditentukan oleh A maka A determinan 

(functional determines) B (B functional dependent A) . Nilai atribut B dapat saja duplikasi, kosong atau 

dapat diubah. Jika a1 dan b1 merupakan nilai A maka akan berpasangan dengan nilai B yang sama 

ataupun berbeda. Jadi A determinan B jika tiap A mempunyai satu pasangan nilai B. Perhatikan

contoh tabel di bawah ini:

Apabila setiap nilai atribut NIM menentukan nama mahasiswa maka dikatakan atribut NIM determinan 

atribut Nama. Begitu juga dengan atribut Jurusan dan Fakultas yang ditentukan oleh NIM. Bentuk 

diagram determinan adalah sebagai berikut:

Dalam kasus lain, ada kemungkinan dua atribut atau lebih secara bersama menentukan atribut lain 

atau determinan komposit (composite determinant/fully functionally dependent) . Sebagai contoh pada 

tabel di bawah, atribut NIM dan atribut MataKuliah menentukan atribut Dosen sebagai pengajar.

Gambar diagram determinannya adalah sebagai berikut:

Sedangkan bila atribut A determinan atribut B dan atribut B merupakan determinan atribut C maka 

atribut A adalah determinan transitif atribut C (C transitive dependency A). perhatikan contoh tabel dan 

diagram determinan di bawah ini:

Dari pembahasan di atas tiap baris dapat diidentifikasikan dengan semua nilai atribut, tetapi akan 

sangat menyulitkan. Oleh sebab itu perlu pemilihan salah satu nilai atribut yang digunakan sebagai 

identitas (identifier) atau elemen kunci (key element) dari baris. Nilai atribut dapat dijadikan identitas 

jika dalam tabel tidak terjadi duplikasi data dan data dengan nilai kosong (NULL).

Normalisasi

Proses normalisasi menyediakan cara sistematis untuk meminimalkan terjadinya kerangkapan data 

diantara relasi dalan perancangan logikal basis data. Format normalisasi terdiri dari lima bentuk, yaitu:

Form Normal Pertama (1NF). Suatu tabel dikatakan sudah 1NF jika telah memenuhi ketentuan 

sebagai berikut:

• Tidak ada atribut mempunyai nilai berulang atau nilai array

• Tidak mempunyai baris yang rangkap

Bentuk unnormal mengijinkan nilai-nilai pada suatu atribut dapat berulang.

Form Normal Kedua (2NF). Relasi dapat dikatakan format normal kedua jika sudah dalam format 

normal pertama dan diikuti kondisi sebagai berikut:

• Key terdiri dari atribut tunggal

• Setiap atribut nonkey ketergantungan fungsional pada semua key atau tidak terjadinya 

ketergantungan pada key composite.

Form Normal Ketiga (3NF). Relasi dikatakan format normal ketiga jika sudah dalam format normal

kedua dan tidak ada ketergantungan transitif diantara atribut.

Form Normal Boyce-Codd (BCNF). BCNF menentukan setiap determinan adalah kunci kandidat

(candidate key).

Form Normal Keempat (4NF). Bentuk ini adalah bentuk normal ketiga atau BCNF dengan nilai atribut

tidak tergantung pada nilai banyak (multivalue dependency).

Form Normal Kelima (5NF). Konsep pada bentuk ini adalah ketergantungan pada gabungan

beberapa atribut (join dependency).

PERANCANGAN BASIS DATA

Permasalahan dalam perancangan basis data adalah bagaimana merancang struktur logikal dan 

fisikal dari satu atau lebih basis data untuk memenuhi kebutuhan informasi yang diperlukan oleh 

pengguna sesuai dengan aplikasi-aplikasi yang ditentukan. [Waliyanto2000]

Dengan permasalahan tersebut dapat ditentukan beberapa tujuan utama perancangan basis data, 

yaitu:

a. Memenuhi kebutuhan informasi sesuai dengan yang diperlukan oleh pengguna untuk aplikasi 

tertentu.

b. Mempermudah pemahaman terhadap struktur informasi yang tersedia dalam basis data,

c. Memberikan keterangan tentang persyaratan pemrosesan dan kemampuan sistem, seperti lama 

tidaknya mengakses data, kapasitas memori yang tersedia dan sebagainya.

Tahapan-tahapan proses perancangan untuk memenuhi tujuan tersebut adalah:

1. Mengumpulkan dan menganalisis persyaratan

2. Merancang konsepsual basis data

3. Memilih Sistem Manajemen Basis Data

4. Merancang logikal basis data

5. Merancang fisikal basis data (pemetaan model data)

6. Implementasi sistem basis data

Dalam pelaksanaan perancangan tersebut terdapat dua kegiatan yang dapat dilakukan secara paralel, 

yaitu perancangan struktur dan isi data (analisis data) dan perancangan pemrosesan data serta 

program aplikasi (analisis fungsional). 

Tahapan rancangan basis data seperti pada bagan di bawah ini tidak secara ketat harus diikuti secara 

berurutan. Karena antara tahap yang satu dengan yang lainnya dapat saling mempengaruhi dan

memberi umpan balik.

Rancangan konsepsual basis data (tahap 2) menghasilkan skema konsepsual dari basis data yang 

bebas dari DBMS tertentu. Dalam hal ini juga digunakan pemodelan bahasa tingkat tinggi seperti 

model E-R (Entity Relationship) atau EER (Enhanced Entity Relationship). Tahap ini juga menentukan 

transaksi data yang dapat dilakukan terhadap sistem basis data.

Rancangan logikal (tahap 4) disebut juga pemetaan model data, yaitu mentransformasikan model 

data yang telah dibuat pada tahap dua ke dalam model data yang sesuai dengan DBMS terpilih. 

Tahap ini juga melakukan perancangan skema eksternal untuk aplikasi yang ditentukan.

Rancangan fisikal basis data (tahap 5) melakukan pendefinisian basis data yang akan disimpan 

sesuai dengan SMBD yang digunakan, meliputi struktur penyimpanan data, format data dan jalur 

akses. Tahap ini disebut skema internal.

Koleksi dan Analisis Persyaratan

Koleksi dan analisis persyaratan merupakan proses pengumpulan dan analisis tujuan dan harapan 

pengguna untuk memperoleh informasi dari sistem basis data. Kegiatan-kegiatan yang dilakukan 

dalam tahapan ini adalah sebagai berikut:

a. Melakukan identifikasi bidang aplikasi dan kelompok pemakai

b. Mempelajari dan menganalisis dokumen yang ada pada aplikasi tertentu

c. Mempelajari sistem yang sedang berjalan

d. Membuat semacam pertanyaan/angket pada calon pengguna yang dipandang potensial untuk 

memperoleh spesifikasi informasi dan proses yang diperlukan.

Perancangan Konsepsual Basis Data

Tahapan ini meliputi dua kegiatan yaitu rancangan skema konsepsual tentang organisasi data yang 

harus disimpan dalam basis data, dan rancangan transaksi yang dilakukan untuk memperoleh 

informasi dari sistem basis data hasil analisis persyaratan pada tahap 1.

Rancangan skema konsepsual

Hasil rancangan konsepsual merupakan pemodelan data dari pemahaman dunia nyata yang 

dituliskan dalam bahasa tingkat tinggi dan tidak terikat dengan DBMS yang akan digunakan. 

Umumnya pembuatan skema konsepsual ini menggunakan diagram E-R.

Untuk menyusun rancanngan konsepsual dimulai dengan identifikasi komponen utama dari skema 

(entitas, hubungan, atribut) dengan mengacu pada karakateristik sebagai berikut:

a. Model data harus cukup memberikan tampilan yang menggambarkan perbedaan jenis data, 

hubungan dan constraint (ekspresif).

b. Model harus dibuat sederhana dan mudah dipahami serta digunakan oleh pengguna.

c. Penyajian model data dibuat dalam diagram yang mudah diinterprestasi

d. Penyajian model data dalam skema harus teliti dan tidak menimbulkan interprestasi (akurat).

Rancangan transaksi

Teknik pembuatan spesifikasi transaski dilakukan dengan melakukan identifikasi data masukan dan 

data keluaran serta sifat fungsional transaksi, sehingga perancang dapat membuat model konsepsual 

transaksi yang tidak terikat dengan sistem.

Fungsi-sungsi model transaksi adalah sebagai berikut:

a. Transaksi pemanggilan (retrieval transaction), yaitu pemanggilan data untuk ditampilkan di layar 

monitor atau dicetak sebagai laporan.

b. Transaksi pembaharuan (update transaction), digunakan untuk pemasukan data baru atau 

perubahan data lama.

c. Transaksi campuran (mixed transaction), digunakan untuk kombinasi pemanggilan data dan 

pembaharuan data.

Pemilihan DBMS

Faktor-faktor yang menentukan pemilihan DBMS antara lain adalah faktor teknik, faktor ekonomi dan 

politik dalam organisasi.

Faktor teknik meliputi kelangsungan dari DBMS untuk diterapkan dalam pengelolaan data seprti jenis 

model DBMS, struktur penyimpanan data dan alur akses data, interface pengguna dan pemrogram, 

jenis bahasa tingkat tinggi dan sebagainya. 

Faktor ekonomi diantaranya pembelian software DBMS, pembelian hardware, biaya pemeliharaan 

sistem, biaya penyusunan basis data dan lain sebagainya. 

Pemodelan Logikal Basis Data

Tujuan dari tahap ini adalah menyusun rancangan konsepsual dan skema eksternal yang sesuai 

dengan DBMS yang dipilih. Langkah-langkah yang dilakukannya adalah:

a. Pemetaan (transformasi data) yang tidak terikat sistem.

b. Penyusunan skema sesuai dengan DBMS.

Perancangan Fisikal Basis Data

Tujuan dari perancangan ini adalah untuk membuat spesifikasi struktur penyimpanan dan jalur akses 

data sehingga diperoleh kemampuan sistem yang baik untuk berbagi aplikasi. Beberapa hal yang 

menjadi pertimbangan dalam perancangan fisikal adalah:

1. Waktu tanggap. Yaitu waktu yang digunakan oleh sistem sejak transaski basis data dimasukkan 

untuk dieksekusi sampai mendapat tanggapan dari sistem. Faktor yang mempengaruhinya adalah 

waktu akses basis data yang dikendalikan oleh DBMS serta dipengaruhi oleh sistem pemuatan 

data (loading) pada komputer, sistem operasi yang digunakan, atau penundaan sistem 

komunikasi.

2. Penggunaan memori komputer. Merupakan kapasitas memori komputer yang digunakan untuk 

menyimpan berkas-berkas basis data dan struktur jalur akses.

3. Transaksi data. Kemampuan melakukan transaksi data tiap satuan waktu merupakan hal yang 

kritis.

Implementasi Sistem Basis Data

Tahap ini merupakan implementasi dari hasil pemodelan logikal dan fisikal. Bahasa yang digunakan 

untuk definisi data atau penyimpanan data yang sesuai dengan DBMS terpilih. Implementasi 

penyusunan basis data dimulai dari pembuatan berkas-berkas data kosong yang akan digunakan 

untuk menyimpan data dalam basis data. Kemudian dilanjutkan dengan pemasukan data untuk tiap 

instansi tabel.

Dalam impelementasi rancangan transaksi, program aplikasi ditulis dengan bahasa manipulasi data 

yang sesuai. Program-program aplikasi yang dibuat harus dilakukan uji coba dulu untuk menguji 

kebenaran program. Setelah diuji kemudian diimplementasikan dalam operasional sistem basis data.

***

Referensi:

[Abdul1999] Abdul Kadir. 1999. Konsep & Tuntunan Praktis Basis Data. Penerbit Andi.

           Yogyakarta.

[David2002] David M. Kroenke. 2002. Database Processing Fundamentals, Design, and

            Implementation. Eight Edition. Pretince Hall.

[Ramez2000] Ramez Elmasri & Shamkant B Navathe. 2000. Database System.

[R.E. 2003] R.E. Wyllys. 2003. Database-Management Principles And Applications.

[Sitansu1991] Sitansu S. Mittra. 1991. Principles of Relational Database Systems. International

             Editions. Prentice-Hall. New Jersey.

[Waliyanto2000] Waliyanto. 2000. Sistem Basis Data Analisis dan Pemodelan Data. J&J Learning.

             Yogyakarta.

Sumber : http://imam_muiz.staff.gunadarma.ac.id/Downloads/folder/0.3