MERANCANG
ARSITEKTUR BASIS DATA
A. Sistem
Basis Data
Tingkat
atau level abstraksi database dibagi menjadi tiga bagian yaitu :
1. Level
fisik ( physical level )
2. Konseptual
( conceptual level )
3. Level
pandangan ( view level )
Basis
data adalah kumpulan data yang saling berelasi. Data sendiri merupakan
fakta mengenai obyek, orang, dan lain-lain. Data dinyatakan dengan nilai
(angka,deretan karakter, atau symbol). Basis data dapat didefinisikn dalam
berbagai sudut pandang seperti berikut:
Himpunan
kelompok data yang saling berhubungan yang diorganisasikan sedemikian rupa
sehingga kelak dapat dimanfaatkan dengan cepat dan mudah.
Kumpulan
data yang saling berhubungan yang disimpan secara bersama sedemikian rupa tanpa
pengulangan (redundancy) yang tidak perlu, untuk memenuhi kebutuhan.
Kumpulan
file/table/arsip yang saling berhubungan yang disimpan dalam media penyimpanan
elektronik.
Basis
data bertujuan untuk mengatur data sehingga diperoleh kemudahan, ketepatan, dan
kecepatan dalam pengambilan kembali. Untuk mencapai tujuan, syarat sebuah basis
data yang baik adalah sebagai berikut;
Tujuan
adanya redundansi dan inkonsistensi data
Redudansi
terjadi jika suatu informasi disimpan di beberapa tempat. Misalnya, ada data
mahasiswa yang memuat NIM, nama, alamat, dan atribut lainnya, sementara kita
punya data lain tentang data KHS mahasiswa yang isinya yang terdapat NIM, nama,
mata kuliah, dan nilai.
2. Kesulitan
Pengaksesan Data
Basis
data memiliki fasilitas untuk melakuakan pencarian informasi dengan menggunakan
Query taupun dari tool untik melihat tabelnya. Dengan fasilitas ini. Kita bias
secara langsung melihat data dari software DBMS-nya. Selain itu, baiss data
bias dihubungkan dengan program aplikasi sehingga memudahkan pengguna dalam
mengakses informasi. Misalnya program aplikasi untuk kasir yang terhubung
dengan basis data . pengguna cukup mengguna fasilitas pencarian ataupun
laporan. Yang tersedia pada program aplikasi untuk mendapatkan informasi stok,
laporan penjualan, dan lain-lain.
3. Multiple
User
Basis
data memungkinkan pengguna data bersama-sama oleh banyak pengguna pada saat
yang bersamaan atau pada saat yang berbeda. Dengan meletakkan basis data pada
bagian server yang bisa diakses kesemua pengguna dari banyak klient, kita sudah
menyediakan akses kesemua pengguna dari computer klient ke sumber informasi
yaitu basis data.
B.
Normalisasi Database
Normalisasi
adalah proses pengorganisasian data dalam database. Ini termasuk menciptakan
Daftar Tabel dan menjalin hubungan antara Daftar Tabel tersebut sesuai aturan
yang dirancang baik untuk melindungi data dan membuat database yang lebih
fleksibel dengan menghilangkan redundansi dan ketergantungan yang tidak
konsisten.
Ada
beberapa aturan untuk database normalisasi. Setiap aturan yang disebut
"bentuk normal." Jika aturan pertama diamati, database dikatakan
dalam "pertama bentuk normal." Jika aturan pertama tiga diamati,
database dianggap berada di "ketiga bentuk normal." Meskipun tingkat
lain dari normalisasi mungkin, bentuk normal ketiga dianggap tingkat tertinggi
yang diperlukan untuk sebagian besar aplikasi.
Seperti dengan banyak peraturan formal dan spesifikasi, skenario dunia nyata
tidak selalu memungkinkan untuk kepatuhan sempurna. Secara umum, normalisasi
memerlukan Daftar Tabel tambahan dan beberapa pelanggan menemukan ini rumit.
Jika Anda memutuskan untuk melanggar salah satu aturan pertama tiga
normalisasi, pastikan bahwa aplikasi Anda mengantisipasi setiap masalah yang
bisa terjadi, seperti data yang berlebihan dan tidak konsisten dependensi.
Bentuk Normal pertama
Menghilangkan
kelompok-kelompok yang berulang dalam Daftar Tabel individu.
Membuat
Daftar Tabel terpisah untuk masing-masing set data terkait.
Mengidentifikasi
setiap rangkaian data terkait dengan bukti kunci primer.
Jangan
gunakan beberapa bidang dalam sebuah Daftar Tabel tunggal untuk menyimpan data
yang sama. Misalnya, untuk melacak item persediaan yang mungkin datang dari dua
sumber yang mungkin, catatan persediaan yang mungkin berisi bidang untuk Vendor
kode 1 dan 2 kode Vendor.
Apa yang terjadi ketika Anda menambahkan vendor ketiga? Menambahkan sebuah
field bukanlah jawabannya; itu memerlukan modifikasi program dan tabel atak dan
tidak lancar mengakomodasi jumlah vendor yang dinamis. Sebaliknya, tempat semua
informasi vendor didalam table yang terpisah yang disebut vendor, kemudian link
persediaan untuk vendor dengan item nomor bukti kunci, atau vendor untuk
persediaan dengan vendor kode bukti kunci.
Kedua
bentuk Normal
Buat
Daftar Tabel terpisah untuk set nilai-nilai yang berlaku tomultiple records.
Berhubungan
Daftar Tabel ini dengan foreign key.
Catatan
tidak boleh bergantung pada apa pun selain bukti kunci primer table (senyawa
bukti kunci, jika perlu). Sebagai contoh, mempertimbangkan alamat penyuratan
pelanggan dalam sistem akuntansi. alamat penyuratan diperlukan oleh Daftar
Tabel pelanggan, tetapi juga oleh pesanan, pengiriman, faktur, Piutang, dan
koleksi Daftar Tabel. Daripada menyimpan alamat penyuratan nasabah sebagai
entri terpisah dalam masing-masing Daftar Tabel, menyimpannya di satu tempat,
atau tabel atak pelanggan alamat penyuratan table yang terpisah.
Bentuk
Normal ketiga
Menghilangkan
bidang yang tidak bergantung pada bukti kunci.
Nilai-nilai
dalam catatan yang bukan merupakan bagian dari bukti kunci catatan yang tidak
termasuk dalam Daftar Tabel. Secara umum, setiap saat isi sekelompok bidang
mungkin berlaku untuk lebih dari satu catatan data dalam Daftar Tabel,
mempertimbangkan menempatkan bidang tersebut didalam table yang terpisah.
Sebagai contoh, dalam Daftar Tabel rekruitmen karyawan, calon Universitas nama
dan alamat penyuratan dapat disertakan. Tetapi Anda perlu daftar lengkap dari
Universitas untuk kelompok surat. Jika informasi Universitas disimpan dalam
Daftar Tabel kandidat, ada cara untuk Daftar Universitas dengan kandidat saat
ini tidak ada. Buat Daftar Tabel perguruan tinggi dengan terpisah dan
menghubungkannya ke tabel atak calon dengan Universitas kode bukti kunci.
PENGECUALIAN: Mengikuti bentuk ketiga normal, sementara secara teoritis
diinginkan, tidak selalu praktis. Jika Anda memiliki Daftar Tabel pelanggan dan
Anda ingin menghilangkan semua dependensi interfield mungkin, Anda harus
membuat Daftar Tabel terpisah untuk kota-kota, kode ZIP, perwakilan penjualan,
pelanggan kelas, dan faktor lainnya yang dapat digandakan dalam beberapa
catatan. Dalam teori, normalisasi bernilai mengerucutkan. Namun, banyak Daftar
Tabel kecil dapat menurunkan kinerja atau melebihi buka file dan kapasitas
kehabisan memori.
Mungkin lebih layak untuk menerapkan bentuk normal ketiga hanya untuk data yang
sering berubah. Jika tetap tergantung beberapa bidang, desain aplikasi Anda
untuk meminta user untuk memverifikasi semua bidang terkait ketika salah satu
berubah.
Bentuk-bentuk
normalisasi
Keempat
bentuk normal, juga disebut Boyce Codd Normal formulir (BCNF), dan bentuk normal
kelima ada, tapi jarang dianggap dalam desain praktis. Mengabaikan
aturan-aturan ini mungkin mengakibatkan desain database kurang sempurna, tetapi
seharusnya tidak mempengaruhi fungsi.
VnPrese3 � " a �� P� '>
2. Immediate update
(update yang segera)
Di teknik ini,
database akan diupdate oleh beberapa transaksi sebelum transaksi mencapai titik point
UNDO/ REDO Recovery based on immediate update in a
single-user
Jika kegagalan terjadi, transaksi yang aktif pada saat terjadi kegagalan menyimpan beberapa
perubahan pada database. Efek dari semua operasi ini harus dibuka (UNDONE).
SHADOW PAGING
Skema recovery ini tidak membutuhkan penggunaan log pada single-user. Pada multiuser,sebuah log mungkin dibutuhkan untuk metode kontrol konkurensi.
Dan itulah yang dapat saya sampaikan,semoga
bermanfaat bagi anda yang mendengar persentasi saya. Sekian dan terima kasih
Tidak ada komentar:
Posting Komentar