PERANCANGAN BASIS DATA,
Definisi Basisdata,
Beberapa definisi basisdata (database) adalah sbb:
- Sekumpulan
data store(bisa dalam jumlah besar) yang tersimpan dalam magnetic disk, optical disk, dan media penyimpan sekunder lainnya.
- Sekumpulan
program-program aplikasi umum yang mengeksekusi dan memproses data secara umum
(hapus,cari,update,dll)
- Basisdata
terdiri dari data yang di-share bagi banyak user dan memungkinkan penggunaan
data yang sama pada waktu bersamaan oleh banyak user.
- Koleksi
terpadu dari data-data yang saling berkaitan dari suatu enterprise.Mis.
Basisdata RS akan terdiri dari data-data seperti pasien, karyawan, dokter,
perawat, dll.
Definisi Perancangan Basisdata,
Perancangan Database adalah proses untuk menentukan isi dan pengaturan
data yang dibutuhkan untuk mendukung berbagai rancangan sistem.
Tujuan Perancangan Database :
• untuk memenuhi informasi yang
berisikan kebutuhan-kebutuhan user
secara khusus dan aplikasi-aplikasinya.
• memudahkan pengertian struktur informasi.
• mendukung kebutuhan-kebutuhan pemrosesan dan beberapa obyek
penampilan (response
time, processing time, dan
storage space).
Proses Perancangan Database,
6 Fase proses perancangan database :
1. Pengumpulan
data dan analisis
2. Perancangan
database secara konseptual
3. Pemilihan DBMS
4. Perancangan
database secara logika
(data model mapping)
5. Perancangan
database secara fisik
6. Implementasi
Sistem
database.
6 fase di atas tidak harus diproses berurutan. Pada beberapa hal,
Rancangan tsb dapat dimodifikasi dari yang pertama dan
sementara itu mengerjakan fase yang terakhir (feedback loop
antara fase) dan feedback loop dalam fase sering terjadi selama
proses perancangan.
Fase 1 :
Pengumpulan data dan analisa
Proses identifikasi dan analisa kebutuhan-kebutuhan data
disebut pengumpulan data dan analisa. Untuk menentukan
kebutuhan-kebutuhan suatu sistem database,pertama-tama
harus mengenal bagian-bagian lain dari sistem informasi
yang akan berinteraksi
dengan sistem
database, termasuk
para pemakai yang ada dan para pemakai yang baru serta
aplikasi-aplikasinya. Kebutuhan-kebutuhan dari para
pemakai dan aplikasi-aplikasi inilah yang kemudian
dikumpulkan dan dianalisa.
Aktifitas-aktifitas pengumpulan data dan analisa :
1. Menentukan kelompok pemakai dan bidang-bidang
aplikasinya.
2. Peninjauan dokumentasi
yang ada.
3. Analisa lingkungan operasi dan pemrosesan
data.
4. Daftar pertanyaan dan wawancara.
Fase 2 :
Perancangan database konseptual
Tujuan dari fase ini adalah menghasilkan
conceptual
schema untuk database yang tergantung pada
sebuah DBMS
yang spesifik. Sering menggunakan
sebuah
high-level data model seperti ER/EER model
selama fase ini. Dalam conceptual schema, kita
harus merinci aplikasi-aplikasi database yang
diketahui dan transaksi-transaksi yang mungkin.
Aktifitas paralel perancangan database secara
konseptual :
1. Perancangan
skema konseptual :
Menguji kebutuhan-kebutuhan data dari suatu database yang
merupakan hasil dari
fase 1, dan menghasilkan
sebuah conceptual database schema pada DBMS
independent
model data tingkat tinggi seperti EER
(enhanced entity
relationship) model.
2. Perancangan transaksi :
Menguji aplikasi-aplikasi database dimana kebutuhan-kebutuhannya
telah dianalisa
pada
fase 1, dan menghasilkan perincian transaksi-transaksi ini.
Fase 3 :
Pemilihan DBMS
Pemilihan
database ditentukan oleh beberapa faktor, diantaranya:
1. Struktur data
Jika data
yang disimpan dalam
database mengikuti struktur
hirarki, maka suatu jenis hirarki dari DBMS
harus dipikirkan.
2. Personal yang telah terbiasa dengan suatu sistem
Jika staf
programmer dalam suatu organisasi sudah terbiasa
dengan suatu
DBMS, maka hal ini dapat mengurangi biaya
latihan dan waktu belajar.
3. Tersedianya layanan penjual
Keberadaan fasilitas pelayanan penjual sangat dibutuhkan
untuk membantu memecahkan beberapa masalah sistem.
4. Teknik
Keberadaan DBMS
dalam menjalankan
tugasnya seperti jenis
-jenis DBMS
(relational, network, hierarchical, dll), struktur
penyimpanan,
dan jalur akses yang
mendukung
DBMS,
pemakai, dll.
Fase 4 :
Perancangan database secara logika
(pemetaan model
data)
Fase selanjutnya
dari perancangan
database adalah :
Membuat sebuah skema konseptual dan skema eksternal
pada
model data dari DBMS
yang terpilih. Fase ini
dilakukan oleh pemetaan skema konseptual dan skema
eksternal yang
dihasilkan pada fase 2. Pada fase ini,
skema konseptual ditransformasikan dari model data
tingkat tinggi yang
digunakan pada fase 2 ke dalam
model data dari DBMS yang dipilih pada fase 3.
Pemetaan diproses dalam 2 tingkat :
1. Pemetaan
system-independent :
Pemetaan ke dalam
model data DBMS dengan tidak
mempertimbangkan karakteristik atau hal-hal yang khusus yang berlaku pada
implementasi DBMS dari model
data tsb.
2 . Penyesuaian skema ke DBMS yang spesifik :
mengatur skema yang
dihasilkan pada langkah 1 untuk disesuaikan
pada
implementasi
yang khusus di masa yang
akan datang dari suatu
model data yang
digunakan pada DBMS
yang dipilih.
Fase 5 :
Perancangan database fisik
Perancangan
database secara fisik merupakan proses
pemilihan struktur-struktur penyimpanan dan jalur-jalur
akses pada
file-file database untuk mencapai penampilan
yang terbaik pada bermacam-macam aplikasi.
Selama fase ini, dirancang spesifikasi-spesifikasi untuk
database yang disimpan yang berhubungan dengan
struktur-struktur penyimpanan fisik, penempatan record
dan jalur akses.
Petunjuk pemilihan perancangan
database secara fisik :
1. Response time
Waktu yang telah berlalu dari suatu transaksi database yang
diajukan
Untuk menjalankan suatu tanggapan. Pengaruh utama pada response
time adalah di bawah pengawasan DBMS yaitu : waktu akses
database
untuk data item yang ditunjuk oleh suatu transaksi.
Response time juga dipengaruhi oleh beberapa faktor yang tidak
berada di bawah pengawasan DBMS, seperti penjadwalan sistem
operasi atau penundaan komunikasi.
2. Space Utility
Jumlah ruang penyimpanan yang digunakan oleh file-file database dan
struktur-Struktur jalur akses.
3. Transaction throughput :
Rata-rata
jumlah transaksi yang
dapat diproses per menit oleh sistem
database,
dan merupakan
parameter kritis dari sistem transaksi (misal, digunakan pada
pemesanan tempat di pesawat,
bank, dll). Hasil dari fase ini adalah penentual awal
dari struktur penyimpanan
dan jalur akses untuk
file-file database.
Fase 6 :
Implementasi sistem database
Setelah perancangan
secara logika dan secara fisik lengkap,
kita dapat melaksanakan
sistem
database. Perintah-perintah
dalam DDL dan
SDL(storage definition language) dari DBMS
yang dipilih, dihimpun dan digunakan untuk membuat skema
database dan file-file database (yang kosong) kemudian
database tsb dimuat (disatukan) dengan datanya.
Jika data
harus dirubah dari sistem komputer sebelumnya,
perubahan-perubahan yang rutin mungkin diperlukan untuk
format ulang datanya yang kemudian dimasukkan ke
database yang baru. Transaksi-transaksi database sekarang
harus dilaksanakan
oleh para programmmer
aplikasi.
ALASAN PERANCANGAN
BASIS DATA,
o Sistem
basis data telah menjadi bagian dalam sistem informasi suatu organisasi.
o Kebutuhan
menyimpan data dl jumlah besar semakin mendesak.
o Fungsi-fungsi dalam organisasi semakin dikomputerisasikan.
o Semakin
kompleks data & aplikasi
yg digunakan, maka relationship antar
data harus
dimodelisasikan.
o Dibutuhkannya kemandirian data.
KONVERSI & LOADING
DATA
oTahap
ini dilakukan apabila sistem basis data yg
ada digantikan sistem basis data baru
oSemua
data yg ada ditransfer ke basis data baru
& konversi aplikasi yg ada utk basis data
baru.
PENGOPERASIAN &
PERAWATAN
o Pengoperasian basis data setelah
divalidasi
o Memonitor
kinerja sistem, jika tidak sesuai perlu reorganisasi basis data
o Perawatan
& upgrade sistem aplikasi basis data jika
diperlukan.
Model Konseptual Basis Data,
Model konseptual merupakan kombinasi beberapa cara untuk
memproses data
untuk beberapa aplikasi. Pada perancangan
model
konseptual
basis data ini penekanan dilakukan pada struktur data
dan
relasi antara
field.
Pada perancangan
model konseptual ini dapat dilakukan dengan
menggunakan
model data relasional.
Teknik Normalisasi
Proses normalisasi
adalah proses pengelompokan
data elemen menjadi
tabel-tabel
yang menunjukkan
entity dan relasinya. Pada proses normalisasi
dilakukan pengujian pada beberapa kondisi apakah ada kesulitan pada saat
menambah/menyisipkan,
menghapus, mengubah dan mengakses pada suatu
Basis data.
Bila terdapat kesulitan pada pengujian tersebut maka perlu dipecahkan relasi
pada beberapa tabel lagi atau dengan kata lain
perancangan
basis data belum
optimal.
Contoh:
- Tabel usermanager yang dapat dinormalisasi ke beberapa aplikasi.
Entity
Entity atau entitas, dalam basis data entity
sama halnya dengan sebuah tabel.
Atribut
Atribut, dalam
basis data sama halnya
dengan
field.
Jenis Atribut
o Atribut Sederhana
o Atribut Komposit
o Atribut Bernilai Tunggal
o Atribut Bernilai Jamak
o Atribut Harus Bernilai
o Atribut Bernilai Null
o Atribut Turunan
Atribut Sederhana
Atribut Sederhana : atribut sederhana merupakan atribut atomik
yang tidak dapat lagi dipecah menjadi atribut lain.
Contoh:
Entitas mahasiswa mempunyai atribut sederhana berupa NIM,
Nama
Mahasiswa .
Atribut Komposit
Atribut Komposit : atribut komposit merupakan atribut yang masih
dapat dipecah menjadi
sub-sub atribut yang
masing-masing
memiliki arti
tesendiri.
Contoh:
Entitas mahasiswa mempunyai atribut alamat. Maka alamat disini dapat
dipecah menjadi sub atribut seperti kota, kab, kode_pos.
Entitas dosen mempunyai atribut nama_dosen. Maka nama disini dapat
dipecah menjadi sub atribut lain
seperti glr_dpn, nama, glr_blk.
Atribut Bernilai Tunggal
Atribut Bernilai Tunggal : atribut yang hanya memiliki satu nilai untuk
setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut NIM,
nama, alamat isi data
dari atribut ini hanya boleh diisi dengan 1
data.
Setiap mahasiswa hanya memiliki 1
NIM, 1 Nama, 1 Alamat.
Atribut Bernilai Jamak
Atribut Bernilai Jamak : yaitu atribut yang boleh memiliki lebih dari
satu nilai untuk setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut
Hobby isi data
dari atribut ini
boleh lebih dari 1
data. Mahasiswa Roshita memiliki NIM
04102002
beralamat di Jalan
Garuda 32 Yogyakarta memiliki Hobby (Olah Raga,
Nyanyi, Masak dan Nonton TV)
Atribut Harus Bernilai (not null)
Atribut Harus Bernilai : yaitu atribut yang harus memiliki nilai data
untuk setiap barisnya. Biasanya atribut seperti ini sudah ditetapkan
dalam perancangan
tabelnya sehingga jika dalam pengisian di kosongi
akan terjadi kesalahan.
Contoh:
entitas mahasiswa mempunyai atribut NIM dan nama_mahasiswa
yang
harus diisi
datanya, sebab jika tidak diisi akan terjadi kesalahan
(error) dalam
basis
data
Atribut Bernilai Null (is null)
Atribut Bernilai Null : yaitu atribut yang boleh tidak memiliki nilai data
untuk setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut
hobby, nama_pacar yang
boleh
tidak terisi.
Atribut Turunan
Atribut Turunan : yaitu atribut yang nilai-nilainya diperoleh dari
pengolahan atau dapat diturunkan dari atribut lain
yang berkaitan.
Contoh:
entitas mahasiswa mempunyai atribut IPK
yang diperoleh dari
pengolahan atribut Nilai pada tabel (entitas Nilai) dengan kode NIM
mahasiswa yang
sama dan diproses sehingga menghasilkan
IPK untuk
mahasiswa yang
bersangkutan.
Field (Atribut) Kunci
setiap
field selalu terdapat kunci berupa
field atau satu set
field
yang dapat mewakili record.
Misalnya Nomor Induk Mahasiswa
(NIM) merupakan
kunci dari tabel mahasiswa suatu Perguruan Tinggi, setiap pencarian
cukup dengan menyebut NIM mahasiswa tersebut maka dapat diketahui
identitas mahasiswa lainnya seperti nama, alamat dan atribut lainnya.
Contoh
lain:
Nomor Pegawai
(NIDN) bagi data
dosen, NIK
untuk data
karyawan,
Kode_Kuliah
untuk data
Mata kuliah, dan lain
sebagainya.
Kunci Kandidat (Candidate Key)
Kunci kandidat adalah satu atribut atau satu set atribut yang
mengidentifikasikan secara unik suatu kejadian spesifik dari entity.
Satu set atribut menyatakan secara tidak langsung dimana anda tidak
dapat membuang beberapa atribut dalam set tanpa merusak
kepemilikan
yang unik.
Kunci Kandidat (Candidate Key)
Contoh:
Kunci kandidat dalam tabel pegawai di disamping
dapat dipilih sbb :
o nik
o no_ktp
o nama_pegawai (tidak dapat dipakai karena sering seseorang punya nama yang
sama dengan orang lain)
o tmp + tgl Lahir (mungkin bisa dipakai sebagai kunci karena kemungkinan orang dengan nama yang sama dan tanggal lahir yang
sama cukup kecil)
o nama + tmp + tgl_lahir (dapat dipakai sebagai kunci)
o alamat dan kota (bukan kunci)
Tabel pegawai berisi
field:
o nik
o no_ktp
o nama_pegawai
o tmp_lahir
o tgl_lahir
o alamat
o kota
Kunci Kandidat (Candidate Key)
Contoh Kasus:
Tentukan Kunci Kandidat dari tabel tersebut
Tabel mt_kuliah berisi
field:
o id_matkul
o kode_matkul
o nama_matkul
o kurikulum
o semester
o sks
o nilai_minimum
Kunci kandidat dalam tabel mt_kuliah di disamping
dapat dipilih sbb :
o id_matkul
o kode_matkul
o nama_matkul (mungkin bisa dipakai sebagai kunci karena kemungkinan nama matkul dengan yang lain ada perbedaan)
o kurikulum + semester + sks + nilai_minimum (tidak dapat dipakai karena sering matkul punya data yang
sama dengan matkul lain)
